AGARD-R-726 


.  I  u... 


/V 


ADVISORY  GROUP  MIR  At  HOSRACt  Rt  St  ARCH  K  OtVHORMtNT 


AGARD  REPORT  No.  726 


The  Influence  of  Large-Scale 
Computing  on  Aircraft  Structural 

Design 


AGARD-R-726 


NORTH  ATLANTIC  TREATY  ORGANIZATION 
ADVISORY  GROUP  FOR  AEROSPACE  RESEARCH  AND  DEVELOPMENT 
(ORGANISATION  DU  TRAITE  DE  L'ATLANTIQUE  NORD) 


AGARD  Report  No.  726 

THE  INFLUENCE  OF  LARGE-SCALE  COMPUTING 
ON  AIRCRAFT  STRUCTURAL  DESIGN 


This  Report  was  sponsored  by  the  Structures  and  Materials  Panel  of  AGARD. 


l>**o 


THE  MISSION  OF  AGARD 


The  mission  of  AGARD  is  to  bring  together  the  leading  personalities  of  the  NATO  nations  in  the  fields  of  science  and 
technology  relating  to  aerospace  for  the  following  purposes: 

—  Exchanging  of  scientific  and  technical  information; 

—  Continuously  stimulating  advances  in  the  aerospace  sciences  relevant  to  strengthening  the  common  defence  posture; 

—  Improving  the  co-operation  among  member  nations  in  aerospace  research  and  development; 

—  Providing  scientific  and  technical  advice  and  assistance  to  the  Military  Committee  in  the  field  of  aerospace  research 
and  development  (with  particular  regard  to  its  military  application); 

—  Rendering  scientific  and  technical  assistance,  as  requested,  to  other  NATO  bodies  and  to  member  nations  in 
connection  with  research  and  development  problems  in  the  aerospace  field; 

—  Providing  assistance  to  member  nations  for  the  purpose  of  increasing  their  scientific  and  technical  potential; 

—  Recommending  effective  ways  for  the  member  nations  to  use  their  research  and  development  capabilities  for  the 
common  benefit  of  the  NATO  community. 

The  highest  authority  within  AGARD  is  the  National  Delegates  Board  consisting  of  officially  appointed  senior 
representatives  from  each  member  nation.  The  mission  of  AGARD  is  carried  out  through  the  Panels  which  are  composed  of 
experts  appointed  by  the  National  Delegates,  the  Consultant  and  Exchange  Programme  and  the  Aerospace  Applications 
Studies  Programme.  The  results  of  AGARD  work  are  reported  to  the  member  nations  and  the  NATO  Authorities  through 
the  AGARD  series  of  publications  of  which  this  is  one. 

Participation  in  AGARD  activities  is  by  invitation  only  and  is  normally  limited  to  citizens  of  the  NATO  nations. 


The  content  of  this  publication  has  been  reproduced 
directly  from  material  supplied  by  AGARD  or  the  authors. 


Published  April  1986 

Copyright  C  AGARD  1986 
All  Rights  Reserved 

ISBN  92-835-1522-6 


Printed  by  Specialised  Printing  Services  Limited 
40  Chigwell  Lane,  Loughton,  Essex  IGI03TZ 


n 


CONTENTS 


Reference 

SUMMARY 

by  A  J.Morris  S 

>  MODERN  TRENDS  IN  AIRCRAFT  STRUCTURAL  DESIGN  ; 

by  H.Godel,  H.Homlein,  D.Keppeler  and  O.Sensburg  N  1 

THE  EFFECTIVE  USE  OF  COMPUTING  POWER  IN  STRUCTURAL  ANALYSIS  ■ 

'  by  I.C.Taig  *  2 

COMPUTER  TECHNOLOGY  AND  ENGINEERING  -  PAST,  PRESENT,  AND  1 995 

by  N.A.Radovcich  J  3 

THE^EEDS  OF  THE  USAF  AIR  LOGISTICS  CENTERS  FOR  LARGE  SCALE  STRUCTURAL 
ANALYSES  AND  SUPRjfeTING  DATA 

by  T.F.Christian,  Jr  4 


IMPACT  OF  COMPUTER  ADVANCES  ON  FUTURE  FINITE  ELEMENT  COMPUTATIONS 
bylLE.Fulton 


5 


S-l 


LARGE  SCALE  COMPUTING  TRENDS  AND  POTENTIAL  AEROSPACE  APPLICATIONS 

SUM4ARY 

Professor  A.J.  MORRIS 
College  of  Aeronautics 
Cranfield  Institute  of  Technology 
Cranfield,  Bedford 
United  Kingdom 

1.  Introduction  ^  >-£  vi  <?  iV 

The  papers  contained  herein  represent  an  attempt  to  review'-the  impact  of  the  modern  revolution  ii\  r 
computing  hardware  in  aerospace  design, and  were  piesented -tir  the  AQARD/3MP ~actrtvTty~4W>?Large — —  ,r‘ 

Scale  Computing  in  Aircraft  Design  in  San  Antonio,  Texas,  USA,  April  198§~.  They  identified  several 
areas  of  potential  application  relevant  to  aeronautical  design  ranging  from  applications  of 
artificial  intelligence  to  the  use  of  computing  power  for  alleviating  management  control  problems. 

The  studies  indicate  that  the  radical  application  of  large  scale  computing  can  have  a  major  impact 
on  the  future  use  of  such  varied  aspects  as  automated  design  techniques,  the  development  of 
extremely  user  friendly  programs,  the  preservation  of  knowledge  and  advanced  monitoring  procedurss.  Yet' 4 
In  this  short  introductory  paper  an  effort  is  made  to  synopsise  these  contributions  in  a  concise  , 

manner  leaving  later  chapters  to  amplify  the  themes  outlined  below.  ' 


2.  Trends  in  Computing  Power 

The  power  and  cost  effectiveness  of  modern  computers  is  increasing  due  to  a  variety  of 
innovative  technological  advances  which  have  taken  place  in  recent  years  and  which  will  be  developed 
in  the  near  future.  The  impact  of  VLSI  on  computer  memory  has  been  dramatic  to  the  extent  that  very 
large  amounts  of  memory  are  now  able  to  be  lodged  on  a  single  chip.  Currently  we  are  looking  at  the 
eight  megabyte  memory  chip  and  developments  in  this  area  will  undoubtedly  lead  to  even  larger  single 
chip  memory  boards.  This  technology  clearly  advances  the  speed  of  the  computer  in  allowing  rapid 
deposition  of  data  on  to  memory  and  subsequent  rapid  accession  of  this  data  into  the  main  computing 
stream.  Nesting  this  type  of  memory  board  into  pipelining  or  DAP  computers  is  inevitably  going  to 
increase  the  computing  power  beyond  those  currently  being  exhibited  by  Cray  II  and  comparable  super 
computers.  On  the  smaller  scale  the  power  of  micro  computers  and  micro  processors  is  similarly 
increasing  at  a  very  rapid  pace.  The  full  32  byte  microprocessor  with  a  cycle  frequency  of  20  MHz 
is  now  available  and  in  the  future  we  would  look  to  this  type  of  machine  being  able  to  perform 
2  megaflops  of  double  precision  and,  in  pipelining  configuration,  up  to  15  megaflops.  By  using 
this  type  of  microprocessor  power  it  is  becoming  possible  to  define  a  floating  point  computing 
engine  with  a  given  power  which  can  interface  with  an  existing  or  new  main  frame  computer.  It  has 
therefore  become  possible  to  define  a  computer  processing  system  which  is  tailored  to  a  specific 
requirement  in  aerospace  or  other  fields.  Indeed,  it  is  possible  to  argue  that  with  the  reduction 
in  cost  it  may  well  be  appropriate  to  define  the  system  which  is-  appropriate  not  just  to  a  particu¬ 
lar  domain  of  application  such  as  aerospace  engineering  but  to  a  precise  application  within  that 
domain,  such  as  Artificial  Intelligence,  or  Advanced  Automated  Design.  We  may  therefore  look  to  a 
multi-operating  system  in  which  a  host  computer  interfaces  with  a  range  of  alternative  computing 
systems  appropriately  configured  for  the  basic  programming  need.  The  host  computer  can  be  thought 
of  either  as  a  serial  type  computer  of  the  type  commonly  used  in  day  to  day  applications  at  the 
present  time  or  it  could  also  be  an  advanced  pipelining  machine  in  its  own  right  which  is  able  to 
more  intimately  dovetail  its  form  of  operation  with  the  parasite  computers. 

This  type  of  approach  would  require  that  the  computer  hardware  manufacturers  were  prepared  to 
produce  co^mters  suitable  to  this  type  of  aerospace  need.  Because  the  aerospace  industry  is  a  very 
small  sector  of  the  market  it  was  made  clear  that  the  industry  could  have  to  be  precise  in  defining 
the  problem  areas  where  developments  were  required;  a  coordinated  approach  would  be  essential  in 
order  to  get  an  adequate  response  from  the  hardware  manufacturers. 

AGARD  can  be  viewed  as  one  forum  in  which  this  type  of  coordinated  approach  could  be  developed  and 
through  it  pressure  brought  to  bear  on  the  appropriate  hardware  developers.  The  remaining  sections 
in  this  short  paper  endeavour  to  define  some  of  these  areas  which  were  highlighted  at  the  San  Antonio 
Mseting  and  which  are  reported  on  in  the  following  articles. 

3.  Integrated  Design 

There  la  a  growing  requirement  which  is  now  well  recognised  for  the  design  process  in  the 
future  to  integrate  many  of  the  disciplines  which  are  used  in  creating  an  aerosnace 
vehicle.  The  various  structural  and  aeronautical  aspects  will  have  to  be  considered  jointly  if  the 
interaction  of  the  one  upon  the  other  is  to  be  fully  exploited,  such  as  when  new  materials,  eg  carbon 
fibre  reinforced  plastics  are  used  extensively  in  the  design  process.  Other  drivers  in  this  area 
come  from  the  need  to  create  large  flexible  structures  which  often  have  to  be  built  to  very  high 
tolerances  for  space  use. 
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This  gives  rise  to  the  complex  CAD/CAM  requirement  in  which  the  lessons  learned  from  IPAD  and 
other  similar  projects  would  have  to  be  incorporated.  The  integrated  design  software  would  accommo¬ 
date  a  multiple  view  of  the  data  in  which,  for  example,  the  design  would  sometimes  be  regarded  from  a 
purely  structural  standpoint  and  at  other  times  would  take  full  account  of  aeronautical  fatigue  and 
management  requirements.  This  process  would  necessarily  require  a  multi-level  data  structure  to 
represent  the  total  design.  Output  from  such  a  relational  database  system  would  then  be  linked  to 
several  discipline  orientated  programs  taking  into  account  structural  optimisation  methods, 
aerodynamic  loads,  finite  element  stress  calculations  etc.  Modem  database  systems  can  handle  this 
kind  of  design  program  and  it  is  quite  feasible  to  think  in  terms  of  creating  a  suitable  finite 
element  machine  to  do  the  necessary  non-linear  dynamic  or  other  analysis  calculations.  This  view  of 
the  design  process  is  expanded  by  the  following  paper  and  is  supported  by  the  MBB  view  that  improved 
quality  and  production  do  require  integrated  software  going  from  mission  analysis  through  aerodynamic 
calculations,  geometry  considerations  and  even  incorporating  wind  tunnel  analysis.  The  MBB  approach 
sees  the  whole  of  this  procedure  being  wrapped  around  optimisation  algorithms  which  are  able  to  take 
account  of  active  control  concepts,  look  at  gust  alleviation  procedures,  take  into  account  flutter 
calculations  and  so  forth. 

The  generation,  development,  and  exploitation  of  this  type  of  large  scale  computing  program 
requires  massive  computational  power.  The  modem  large  scale  computers  of  the  Cray  II  type  would  be 
able  to  handle  certain  of  the  issues  by  this  type  of  approach  but  clearly  would  not  be  able  to  cover 
the  full  range  of  computational  and  data  management  required  to  be  able  to  combine  most  of  the  design 
aspects  thought  necessary  in  such  an  integrated  program.  Several  contributors  see  integrated  programs 
as  being  one  of  the  drivers  and  motivators  to  the  exploitation  and  future  generation  of  the  large 
scale  computing  capacity  touched  on  in  section  2. 


4.  Management  and  Control 

One  of  the  major  problems  in  controlling  and  organising  a  large  fleet  of  aircraft  is  to  ensure 
that  the  structural  integrity  of  each  individual  aircraft  is  maintained  at  all  times  throughout  its 
useful  life.  Currently  this  problem  is  being  faced  by  the  US  Air  Force  and  the  Air  aft  Structural 
Integrity  Program  and  Damage  Tolerance  Analysis  Procedures  have  been  set  up  to  endeavour  to  follow 
each  aircraft  on  a  flight  by  flight  analysis.  This  is  supported  by  the  Aircraft  Information  Retrieval 
System  which  is  an  advanced  management  tool  allowing  each  aircraft  to  be  tracked  and  a  repair  program 
to  be  set  up  to  effectively  maintain  the  integrity  of  aircraft  in  service  at  all  times.  It  is  also 
intended  to  allow  repair  schemes  to  be  created  and  clearances  given  at  a  moment's  notice  for  aircraft 
that  might  be  required  for  combat  usage.  The  main  problem  in  generating  this  type  of  complex  software 
to  manage  the  flight  programs  of  individual  aircraft  lies  in  creating  appropriate  data  bases  using 
pre  and  post  processors.  The  concept  behind  this  type  of  program  is  fairly  clear  and  straightforward. 
However  the  problem  of  inputting  the  required  data  in  a  suitably  structured  form  and  subsequently 
retrieving  it  in  an  effective  manner  is  far  from  solved  and  will  require  very  large  computing 
capabilities. 

Whilst  it  is  possible  to  believe  that  the  current  large  scale  computers  are  able  to  handle  the 
data  required  for  the  ASIP  and  the  AIRS  programs,  when  consideration  is  given  to  the  extension  of  this 
type  of  philosophy  to  systems  involving  not  only  structural  aspects  but  also  avionics  systems,  engines, 
etc.  it  is  clear  that  the  current  range  of  computers  is  inadequate  for  the  task  to  be  handled. 


S.  Artificial  Intelligence 

The  use  of  integrated  design  programs  appears  to  offer  the  user  the  easy  method  for  forming 
elaborate  and  complex  design  and  analyses.  However  modem  CAD/CAM  systems  are  extremely  elaborate 
and  complex  themselves  and  require  very  specialist  knowledge  to  be  effectively  used.  Extending 
this  type  of  complexity  to  the  integrated  design  program  would  require  such  elaborate  specialisation 
on  the  part  of  the  user  that  the  programs  in  many  ways  would  be  self  defeating  since  they  would  now  be 
inaccessible  to  the  design  community.  In  order  to  make  very  advanced  computer  programs  accessible  to 
the  design  engineer  attention  is  now  focussing  on  the  use  of  artificial  intelligence  as  a  way  of 
holding  knowledge  within  the  computer  and  instructing  and  guiding  the  user  of  complex  programs  in 
their  use  and  giving  assistance  to  avoid  abuse.  The  approach  proposed  by  British  Aerospace  extends 
this  concept  to  taking  into  account  the  fact  that  many  aircraft  design  engineers  are  now  reaching 
retirement  and  their  knowledge  will  be  lost  to  the  companies  unless  action  is  taken.  Hie  idea 
proposed  by  BAe  is  therefore  to  create  special  programs  which  till  preserve  the  company's  knowledge 
and  also  allow  advanced  programs  to  be  used  within  the  same  network  of  artificially  intelligent 
programs . 

The  use  of  complex  languages  such  as  PROLOG  and  LISP  places  a  great  strain  on  computers  and  in 
many  cases  dictates  that  a  high  level  of  parallel  computing  should  be  performed.  In  order  to  create 
effective  programs  in  the  aircraft  design  areas  extremely  versatile  computers  will  be  required.  The 
concept  of  the  'conformable'  computer  is  one  which  is  advanced  in  this  area.  This  concept  envisages 
a  computer  with  a  multiple  processing  capacity  which  is  itself  able  to  make  decisions  about  when  to  run 
the  programs  sequentially  and  when  to  co-routine.  Such  a  computer  would  also  be  able  to  support  the 
heavy  numerical  computation  requirements  laid  down  by  the  integrated  design  programs, calling  up 
structural  optimisation  and  finite  element  programs  as  well  as  being  able  to  support  the  AI  aspects 
which  would  be  lodged  within  this  type  of  program  in  future. 
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6.  Conclusion 


The  papers  presented  in  the  sequal  clearly  emphasise  that  large  scale  computing  hardware  has  a 
major  role  to  play  in  future  aeronautical  design.  It  is  also  clear  that  certain  advances  will  hinge 
not  only  on  the  availability  of  current  advanced  computers  but  on  further  advances  that  are  foreseen 
in  the  near  to  medium  term.  An  important  aspect  which  emerges  from  the  papers  is  that  the  old  idea 
of  regarding  aircraft  design  within  clearly  defined  disciplines  such  as  structures,  aerodynamics, 
systems,  etc,  will  not  be  applicable  when  large  scale  computing  hardware  is  freely  available  and 
exploited  for  the  design  of  advanced  aerospace  vehicles . 
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MODERN  TRENDS  IN  AIRCRAFT  STRUCTURAL  DESIGN 
by 

H.  GOdel 
H.  Hdrnlein 
D.  Keppeler 
O.  Sensburg 

MESSERSCHMITT-BOLKOW-BLOHM  GmbH. 
Helicopter  and  Airplane  Division 
P.O.  Box  801160,  8  Munich  80 
W. -Germany 


Summary 

This  paper  deals  mainly  with  the  usage  of  supercomputers  in  structural  optimization. 

To  employ  an  integrated  design  strategy  where  several  disciplines  of  aircraft  structural 
design  must  cooperate  -  mainly  loads,  flight  control  system,  stress  and  static  aeroelastics- 
optimization  program  architecturs  become  more  and  more  complex.  It  is  also  necessary  to  re¬ 
present  and  optimize  the  structure  -  especially  in  highly  loaded  areas  -  with  a  large  num¬ 
ber  of  finite  elements  in  order  to  achieve  weight  reductions.  It  is  shown  that  supercompu¬ 
ters  could  make  the  automated  structural  design  problem  feasible. 


1 .  INTRODUCTION 


In  the  first  applications  of  structural  optimization  it  was  tried  to  put  the  intui¬ 
tive  physical  criteria  of  optimality  into  algorithms.  This  procedure  gave  nonlinear  re¬ 
lations  which  had  to  be  truncated  in  order  to  get  easy  to  use  redesign  formulas.  This 
approach  is  the  well-known  Optimality  Criteria  method  (OC) .  The  OC  methods  are  appro¬ 
priate  to  provide  the  "optimal  design"  of  very  special  structural  problems  under  severe 
restricting  assumptions.  The  stress  rationing  method,  for  example  leads  to  a  fully  stres¬ 
sed  design  (FSD) ,  but  this  is  the  optimal  design  only,  if  the  structure  is  statically 
determinate,  if  the  used  material  has  the  same  properties  for  all  elements  and  if  only 
stress  constraints  are  imposed.  Not  even  the  deflection  constraints  which  are  in  linear 
relation  to  the  stress  constraints  can  be  handled  simultaneously  by  this  approach. 

The  development  of  further  redesign  formulas  in  order  to  deal  with  distinct  con¬ 
straints  leads  to  an  interactive  procedure.  This  approach  however  is  questionable  be¬ 
cause  it  is  a  priori  not  known  which  constraints  are  active  in  the  optimal  design. 

The  simultaneous  consideration  of  all  constraints  was  not  possible  until  the  Mathe¬ 
matical  Programming  methods  (MP)  were  employed.  The  MP  methods  which  are  independent  of 
physics,  supply  the  necessary  generalization  for  the  treatment  of  physically  di.,erent 
constraints.  The  development  of  the  MP  methods  however  did  not  aim  at  the  solution  of 
nonlinear  physical  problems  but  was  applied  only  on  linear,  quadratic  or  at  best  on  non¬ 
linear  convex  models.  For  that  reason  the  application  of  MP  methods  is  also  restricted  to 
some  assumptions.  No  global  theory  for  multimodal  problems  excists  so  only  local  solu¬ 
tions  can  be  found.  It  is  necessary  for  the  future  development  of  structural  optimiza¬ 
tion  to  deal  with  the  specific  properties  of  "real  life"  problems  and  to  revise  the  MP 
methods . 


2.  STRUCTURAL  OPTIMIZATION  USING  MATHEMATICAL  PROGRAMMING 

The  task  of  structural  optimization  consist  in  the  determination  of  optimal  values 
of  design  variables  xtR#  which  minimize  a  selected  objective  function  f  :  Rn-»R, 
while  satisfying  imposed  constraints  g-j  (x)  »  0;  j  •  J.  A  typical  example  is  minimizing 
weight  subject  to  stress  constraints.  The  problems  may  be  classified  by  the  type  of  cho¬ 
sen  design  space.  Three  different  types  of  design  variables  are  usually  considered, 
see  Fig.  1.  Each  class  of  design  space  requires  different  appropriate  solver.  Ideally 
all  kinds  of  design  variables  should  be  handled  simultaneously.  In  practice,  this  is 
done  consecutively  because  of  the  differences  in  numerical  behaviour. 

Another  kind  of  classification  arises  from  the  different  physical  properties  of  the 
constraints,  but  these  problems  must  be  handled  simultaneously,  see  Fig.  1. 
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Classification  by  tne  type  of  choosen  design  space 
.  sizing  variables  actual  design  of  members 

.  geometrical  variables  =>  shape  design  of  structure 
.  topological  variables  =>  arrangements  of  members 


Classification  by 
.  static  =» 

.  dynamic 
.  aeroelastic  => 


the  kind  of  considered 
stress,  displacement, 
frequency,  response 
efficiency,  flutter-. 


constraints 

buckling 

divergence  speed 


FIG.  1  CLASSIFICATION  OF  PROBLEMS 


The  general  nonlinear  programming  (NLP)  problem 


NLP 

min 

f  ( x )  x  e  F1” 

s.t. 

9j  ( X )  SO 

is  usually  attempted  to  be  solved  by  two  different 
Iterative  procedures. 


FIG.  2  TWO  SCHOOLS  OF  THOUGHT  :  MP-OC 


MP 

Mathematical  Programming 

x  ':=x  ♦ 

ocv  s'1’ 

where  s* 

is  search  direction 

and 

OC* 

Is  step  size 

OC  Optimality  Criteria 


x,  *  +1  :=  >  (x^  > 


1  =  1 . m 

where  >  is  an  appropriate 
recui  rente  i elal ion 


In  general,  the  structural  optimization  problem  is  well  modelled  as  a  nonlinear  pro¬ 
gramming  problem  (NLP) ,  see  Fig.  2.  As  mentioned  in  the  introduction  there  are  two  schools 

of  thought  and  there  is  an  age-old  dispute  between  the  supporters  of  Mathematical  Pro¬ 
gramming  (HP)  and  Optimality  Criteria  (OC) .  In  reality  there  is  no  difference  in  prin¬ 
ciple  between  these  schools  of  thought.  Duality  makes  it  simply  clear  that  the  OC  school 
has  always  tried  to  solve  the  dual  problem.  The  recurrence  relations  (redesign  formulas) 
used  in  the  OC  methods  offer  nothing  else  than  the  iterative  fulfilment  of  the  necessary 
first  order  conditions  (Kuhn-Tucker  Conditions)  for  local  optimality.  However,  these  non¬ 
linear  conditions  often  were,  and  still  are,  greatly  simplified  in  order  to  obtain  recurren¬ 
ce  relations  that  can  easily  be  dealt  with.  It  is,  therefore,  no  real  surprise  that  the 
solutions  found  represent  mainly  mere  approximations  of  the  true  optimum. 

The  observation  that  the  OC  methods  also  belong  to  the  MP  methods  is  not  new.  C.Fleury 

and  others  repeatedly  emphasized  this  years  ago  and  appealed  for  the  settling  of  the  dis¬ 
pute  between  these  only  seemingly  different  schools  of  thought. 

The  MP  methods  are  usually  divided  into  two  categories,  see  Fig.  3.  The  use  of  Trans¬ 
formation  Methods  is  as  popular  now  as  it  was  before.  In  this  case,  however,  the  idea  of 
"augmented  Lagrangian"  -  also  known  as  Method  of  Multipliers  -  seems  to  find  acceptance. 

The  arising  unconstrained  problems  are  solved  using  the  well  known  quasi  Newton  methods 
(DFP ,  BFGS) .  The  self  scaling  variable  matric  algorithms,  which  were  put  forward  by  S.S. 
Oren  and  D.G.  Luenberger  could  still  produce  improvements.  This  scaling  possibly  makes  the 
quasi  Newton  method  more  stable  against  non-exact  line  search,  since  the  deterioration  of 
the  condition  of  the  updated  inverse  Hessian  is  prevented. 

Trans forsat ion  Methods 

,  Barrier  functions 
,  Penalty  functions 

.  Methods  of  multipliers  (augmented  Lagrangian) 


PrlMal  Methods 

.  Sequential  linear  programming  (SLP) 
.  Recursive  quadric  programming  (RQP) 
.  Gradient  projection  methods 
.  Generalized  reduced  gradients  (GRG) 
.  Method  of  feasible  directions  (MFD) 


Frequently  used  HP  Methods 

All  MP-methods  are  based  on  solving  the  local  Kuhn- 
Tucker  conditions.  These  methods  are  usually  divided 
into  two  categories: 


FIG.  3  MATHEMATICAL  PROGRAMMING  METHODS 
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Without  going  into  further  details,  let  it  be  mentioned  that,  as  the  Primal  Methods,  , 

besides  the  Sequential  Linear  and  Recursive  (sequential)  Quadratic  Programming  (SLP,  RQP)  , 
the  methods  of  Generalized  Reduced  Gradients  (GRG)  as  well  as  those  of  Projected  Gradients, 
are  also  being  successfully  used.  Zoutendijk's  idea  (Method  of  Feasible  Directions)  is 
still  very  often  applied. 

Designing  a  structural  optimization  program  system  there  are  some  items  in  view  of  1 

mathematical  programming  which  should  be  regarded. 

o  Development  of  in-house  programs  gives  familiarity  with  the  details. 

o  Sensitivity  analysis  plays  a  crucial  part  in  structural  optimization  (CPU  time  con- 
suming) . 

o  Variable  linking  is  necessary  to  handle  large  scale,  symmetric  and/or  antisymmetric 
problems  with  a  lot  of  fixed  variables  and  production  requirements  respectively. 

o  Temporary  disregard  of  "inactive"  constraints  by  suitable  "active  set"  strategies 
saves  computer  time. 

o  Use  explicit  constraints  approximations  for  active  constraints, 
o  Scaling  of  constraints  and  variables  makes  the  numerical  problems  well  behaved. 

** 

3.  STRUCTURAL  OPTIMIZATION  IN  THE  GENERAL  DATA  FLOW 

The  use  of  structural  optimization  tools  during  the  preliminary  design  stage  of  an 
advanced  aircraft  gives  the  following  potential  improvements. 

o  satisfying  the  requirements  of  recent  aircrafts. 

o  minimizing  the  objective  (weight) 

o  increasing  the  quality  of  products. 

o  shortening  the  development  phase. 

o  increasing  chances  of  the  company  in  competition 


In  order  to  do  this, an  appropriate  mathematical  programming  procedure  has  to  be  em¬ 
bedded  in  the  general  data  flow,  which  is  depicted  in  Fig.  4  and  Fig.  5. 


FIG,  4  EXTERNAL  GEOMETRY  IN  DATA  FLOW 
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MBB-LAGRANGE  /  ID 
INTEGRATED  DESIGN 


PRELIMINARY  DESIGN  FINAL  DESIGN 


FIG.  5  GENERAL  DATA  FLOW 


These  figures  show  a  typical  flow  of  geometric,  aerodynamic,  structural  and  other 
data  which  are  used  during  the  design  phase  of  an  aircraft.  The  improved  productivity  is 
a  result  of  the  Integrating  effects  of  the  structural  optimization.  Shorter  time  of  deve¬ 
lopment  would  be  expected  and  fewer  data  transfer  would  go  wrong. 

At  the  present  time  the  development  of  a  recent  aircraft  is  influenced  by  new  techniques, 
such  as  flutter  suppression,  CCV-conf iguration ,  gust  load  alleviation  etc,  see  Fig.  6. 


FIG.  6  NEW  TECHNIQUES  OF  RECENT  AIRCRAFTS 
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In  addition  to  stress,  displacement,  areoelastic  and  dynamic  constraints  an  integra¬ 
ted  design  involves  all  these  techniques  and  the  optimization  procedures  must  be  extended 
for  these  new  constraints. 


4 .  STRUCTURAL  OPTIMIZATION  AT  MBB 

After  several  years  of  using  and  modifying  some  optimization  programs  (FASTOP,  TSO) , 
MBB  is  now  developing  an  own  structural  optimization  system  called 

MBB  -  LAGRANGE 

Fig.  7  shows  the  intended  potential  performance  of  this  new  program  system. 

1 .  REQUIREMENTS 

FINITE  ELEMENT  STRUCTURE 

2  .  STRUCTURE  VARIABLES  x  e  ]Rm 

O  SKIN  THICKNESS 

O  BALANCE  MASSES 

O  FIBRE  DIRECTIONS 

o  NODE  CO-ORDINATES 

3.  CONSTRAINTS  g . (x)  *  0,  jfej 

o  MIN/MAX  -  VARIABLE 
O  STRESSES 

o  STRAINS 
o  DEFORMATIONS 

O  FLUTTER  SPEED 
o  DIVERGENCE  SPEED 

O  AEROELASTIC  EFFICIENCIES 
O  EIGEN  FREQUENCIES 

o  ELEMENT  STABILITY 

O  SYSTEM  STABILITY 
o  DYNAMIC  RESPONSE 
o  WEIGHT 

4.  MULTIOBJECTIVE  FUNCTION  f (x)  -»Min. 

VECTOR  OPTIMIZATION  =  "TRADE  OFF"  STUDIES  OF 

CONVEX  COMBINATION  OF  OBJECTIVES 

FIG.  7  INTENDED  POTENTIAL  PERFORMANCE  OF  PROGRAM  SYSTEM  LAGRANGE 


The  basic  considerations  designing  a  new  optimization  procedure  are  listed  in  Fig.  8. 
This  figure  shows  the  most  accepted  trends  in  the  development  of  structural  optimization 
systems. 

o  SEVERAL  OPTIMIZATION  METHODS  FOR  COMBINING  THEM  DEPENDENT 
ON  THE  PHYSICAL  PROBLEM,  CONSTRAINTS  . . . 

o  ENGINEERING  MODULUS  FOR  SOLVING  SYSTEM  EQUATIONS 

o  IMPROVE  FINITE  ELEMENT  LIBRARY  ESPECIALLY  FOR  COMPOSITE 
MATERIALS 

O  MODUL  FOR  QUASIANALYTICAL  SENSITIVITY  ANALYSIS  AND  METHODS 
FOR  CALCULATION  OF  NUMERICAL  GRADIENTS 

o  ARCHITECTURE  FOR  HIGH  MODULARITY  TAKING  IN  ACCOUNT  THE  CAPABILITIES 
OF  SUPERCOMPUTER,  USE  SCIENTIFIC  DATABASE  FOR  MODULARITY 


FIG.  8  TRENDS  IN  THE  DEVELOPMENT  OF  STRUCTURAL  OPTIMIZATION  SYSTEMS 


5. 


CPU  TIME  EXPENSE  IN  AEROELASTICS 


Two  general  equations  for  the  solution  of  the  static  aeroelastic  problem  are  given 
in  Fig.  9.  Solving  the  equation  for  the  displacement  derivatives  the  big  amount  of  CPU 
time  is  mainly  demanded  by  the  large  number  of  design  variables  and  also  by  the  number 
of  iteration  steps .  in  Fig.  10  a  formula  for  the  estimation  of  the  total  number  of  opera¬ 
tions  is  depicted.  An  estimation  for  an  example  with  reasonable  size  provides  2  •  1010 
operations,  that  is  a  CPU  time  of  about  5  hours  on  an  IBM  computer  for  one  optimization 
step,  of  course.  An  approach  using  the  mentioned  formulae  for  the  example  in  question 
would  result  in  a  prohibitive  cost. 


I)  K  (t)  •  x  <t)  -  A  .X(t)  *  k 


II) 

Kct$r^  » 

A  3x  <t>  . 

"  d 

K  (t) 

X  (t) 

3‘i 

_ 

9  tj 

1_  ati 

(EQUILIBRIUM) 


(DERIVATIVES) 


K  ;  STIFFNESS  MATRIX 

A  :  AERODYNAMIC  MATRIX 

X  :  DEFORMATION  VECTOR 

k  :  LOAD  VECTOR 

t  :  DESIGN  VARIABLE 

>  :  INDEX  OF  DESIGN  VARIABLE 

FIG.  9  SENSITIVITY  ANALYSIS  FOR  STATIC  AEROELASTIC 


N  0.2nbz  +  Ims  (a*  +•  4.25  nb) 


TOTAL  NUMBER  OF  OPERATIONS  (1  MULT  I  PL  I KAT ION  +  1  ADDITION  + 

1  STORE) 

DEGREES  OF  FREEDOM  OF  THE  STRUCTURE  (2000) 

BANDWIDTH  OF  STIFFNESS  MATRIX  (400) 

AERODYNAMIC  ELEMENTS  (1000) 

NUMBER  OF  LOAD  CONDITIONS  (1) 

DESIGN  VARIABLES  (500) 

ITERATION  STEPS  (20) 

N(EXAMPLE)a  2  •  11)10  0PERAT10NS  (AB0UT  5  H0URS  CPU  0N  1BM) 

FIG.  10  OPERATION-COUNTING  FOR  THE  ABOVE  SENSITIVITY  ANALYSIS 

A  reasonable  way  to  save  computer  time  in  structural  optimization  is  to  regard  some 
general  rules  which  are  given  below,  but  the  success  would  be  rather  modest. 

o  reduce  number  of  degreee  of  freedoms 

o  reduce  number  of  design  variables 

o  reduce  number  of  aerodynamic  elements 

o  optimize  band  width  of  stiffness  matrix 

o  optimize  iterative  solution 

A  much  higher  decrease  of  CPU  time  can  be  expected  by  using  certain  optimization 
methods  for  which  very  fast  procedures  for  the  sensitivity  analyses  exist.  These  proce- 


N 

n 

b 

a 

l 

m 

.s 


SOLUTION  OF  I  AND  II 
ITERATIVELY 
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dures  exploit  the  special  characteristics  of  the  optimization  methods  in  mind.  Neverthe¬ 
less,  the  reductions  and  optimizations  mentioned  above  should  be  done  whereever  it  is 
possible. 

In  the  future, structural  optimization  will  be  done  using  high  speed  supercomputer 
with  big  memory  capability. 


6.  STRUCTURAL  OPTIMIZATION  USING  SUPERCOMPUTERS 

An  important  point  in  view  of  structural  optimization  is  the  performance  of  today’s 
and  future  supercomputers.  Fig.  11  shows  characteristic  data  of  some  well-known  computers. 
The  MFLOP  rates  in  this  figure  are  highly  theoretical.  In  practice,  however,  an  average 
of  10  to  30%  of  the  speed  values  seems  to  be  realistic. 


TYPE 

MEMORY  (M  WORD) 

THEORETICAL  (M  FLOPS) 
SPEED 

CLOCK  (N  SEC) 
CYCLE 

ADDITIONAL 

MEMORY 

IBM  3084 

8 

8 

26 

NO 

SIEMENS 

VP  200 

32 

536 

7.5 

... 

CRAY-X-MP 

48 

8 

1260 

9.5 

YES 

CDC  CYBER 
205 

16 

800 

20 

YES 

FIG.  11 

The  ratio  of  wall  clock  times  of  scalar  mainframe  to  supercomputer  is  like  hours  to 
minutes.  The  performance  of  future  supercomputers  available  in  a  few  years  is  shown  in 
Fig.  12. 


TYPE 

MEMORY  (M  WORD) 

THEORETICAL  (M  FLOPS) 

CLOCK  (N  SEC) 

8  BYTE 

SPEED 

CYCLE 

CRAY-2 

256 

2000 

4 

ETA  10 

128 

10.000 

4 

FIG.  12 

Some  aspects  are  given  in  the  following  for  the  design  of  a  structural  optimization 
system  with  special  respect  to  supercomputer. 

o  Extreme  performance  by  vectorization,  large  physical  memory  and  multitasking  demand 

for  a  very  new  design  of  the  structural  optimization  system  using  the  above  possibili¬ 
ties  in  a  special  manner. 

o  Minimize  wall  clock  time 

make  a  design  to  maximize  vectorization 

minimize  scalar  CPU  time  (especially  in  finite  element  codes) 
make  an  efficient  data  management  to  minimize  I/O  wait  time. 

o  In  core  solutions  will  become  more  important. 

o  Vectorization  and  the  possibility  of  virtual  memory  may  be  contradictory. 

o  Recomputing  may  be  some  times  more  efficient  than  any  data  transfer. 

o  An  adjusted  data  base  is  necessary  for  the  optimization  of  different  types  of  struc¬ 

tures.  Requirements  for  a  data  base  should  be  such  as. 

logical  independence  of  data 
independent  of  computer  type 
FORTRAN  interface 
variable  record  length 

handlinq  of  extensive  data  (matrices,  vectors) 
multi  user  operation 
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THE  EFFECTIVE  USE  OF  COMPUTING  POWER  IK  STRUCTURAL  ANALYSIS 


by  Ian  C.  Taig 

British  Aerospace  P.L.C.,  Aircraft  Group  -  Warton  Division 
Harton  Aerodrome,  Preston  PR4  1AX  England. 


SUMMARY 

This  paper  supplements  earlier  surveys  of  the  potential  structural  applications  of 
large  scale  computing  by  introducing  two  factors  not  previously  considered.  These  are 
a  major  conceptual  change  in  the  task  of  modelling  for  finite  element  analysis,  made 
feasible  by  cost-effective  large  number-crunching  capacity,  and  the  emergence  of  expert 
systems  techniques  to  broaden  the  scope  and  increase  the  effectiveness  of  large  scale 
computing. 

These  two  factors  allied  to  the  data  handling  and  storage  needed  to  manage  them, 
can  lead  to  demands  for  two  to  three  orders  of  magnitude  increases  in  computing  power  in 
the  next  decade.  They  may  also  influence  the  computer  hardware  configurations  required. 


1.  INTRODUCTION 

In  most  previous  surveys  of  large-scale  computing  (e.g.  in  the  recent  report  (1)  to 
the  Fluid  Dynamics  Panel),  the  trends  in  structural  computing  are  presented  as  fairly 
straightforward  extrapolations  from  today's  requirements.  This  leads  to  an  inevitable 
conclusion  that,  as  regards  large-scale  computing  in  aeronautics,  it  is  mainly  fluid 
mechanics  which  will  set  the  demands  while  structures  will  use  up  (hopefully  effectively) 
some  of  the  capacity  made  available  to  meet  these  demands.  This  is  because  structural 
computing  using  FE  methods  has  reached  a  temporary  plateau  where  MOST  of  the  things 
deemed  ESSENTIAL  can  already  be  done  -  at  a  cost  and  in  a  timescale  which  industry  has 
come  to  accept  as  the  norm.  Further  advances,  through  the  availability  or  more  and 
cheaper  number-crunching,  storage  and  data  handling  are  seen  as  contributing  to  larger 
and  more  extensive  optimisations,  more  iterative  cycles  and  hence  more  non-linear 
capability,  longer  and  more  representative  dynamic  analyses  and  so  on. 

This  view  can  be  summarised  in  the  grossly  oversimplified  statement: 

"Further  advances  in  structural  computing  represent  increments  on  a  curve  of  diminishing 
returns,  which  are  justified  mainly  by  the  improved  cost-effectiveness  of  computing  power, 
rather  than  by  necessary  technical  advance". 

Whilst  there  is  a  large  element  of  truth  in  this  view,  it  overlooks  two  facts  which  may 
have  a  very  significant  bearing  on  how  we  analyse  and  design  structures;  we  may  not 
simply  be  looking  for  "more  of  the  same,  but  a  lot  cheaper”. 

The  first  is  that,  as  capability  to  analyse  in  greater  detail  increases,  our 
conception  of  the  crucial  task  of  structure  modelling  could  undergo  a  radical  change. 

At  present  the  practical  scale  of  analysis  (dictated  by  the  ability  to  prepare,  validate 
and  handle  the  data  as  much  as  by  central  computing  capacity)  falls  far  short  of  the 
"ideal"  in  which  local  and  global  behaviours  can  be  handled  by  a  continuous  set  of 
calculations.  We  refer  to  this  as  the  question  of  "scale  compatibility”. 

The  second  important  fact  is  that  the  finite  element  "black  box"  analysis  packages, 
now  universally  available,  provide  as  much  capability  for  incompetent  and  Ineffective 
analyses  as  for  effective  use.  Poor  results  can  be  produced  faster,  larger  and  larger 
models  created,  whether  necessary  or  not,  by  the  mesh  generators  and  modellers.  The 
new  emerging  fact  is  that  we  are  learning  how  to  inject  not  only  "intelligence"  but  also 
the  fruits  of  experience  into  computing  systems.  The  new  generation  of  software/ 
hardware  tools  for  analysts  and  designers  will  significantly  alter  the  computing  balance 
between  solving  the  numerical/mathematical  problem  on  the  one  hand  and  formulation  and 
interpretation  (in  real  world  terms)  on  the  other.  We  refer  to  this  as  "assisted 
utilisation" . 

These  two  issues  will  be  considered  before  returning  to  the  question  of  structural 
demands  for  large-scale  computing. 

2.  SCALE  COMPATIBILITY  AND  A  NEW  VIEW  OF  MODELLING 

In  airframe  structures  it  is  not  yet  feasible  to  handle,  in  a  single,  coherent  set 
of  analyses,  all  structural  problems  from  global  stress/displacement  distribution  down 
to  stress  concentration  around  a  crack  or  in  the  individual  layers  of  a  laminate.  This 
is  one  essential  difference  between  structural  and  fluid  mechanics  analyses,  which  we  can 
summarise  by  comparing  the  scale  of  significant  physical  behaviour  with  the  scale  of 
geometric  features  which  cause  that  behaviour.  In  fluid  mechanics,  representation  of 
the  'determining  geometry'  is  a  relatively  minor  problem  -  the  physical  phenomena  them¬ 
selves  need  modelling  down  to  a  scale  (in  space  and  time)  which  is  far  more  demanding. 

In  structures,  it  is  at  the  limits  of  current  computing  power  just  to  describe  the 
geometry  down  to  the  last  significant  detail  and  one  to  three  orders  of  magnitude  beyond 
these  limits  to  produce  a  total  and  coherent  set  of  analyses  spanning  the  whole  scale 
range.  We  can  currently  only  manage  a  two  or  three  -  stage  process  in  which  the  truly 
local  analysis  is  concentrated  in  areas  identified  as  critical  by  a  coarser,  higher  level 
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study  or  by  test.  Even  sub-structure  analysis,  which  is  meant  to  bridge  this  gap, 
rapidly  becomes  too  unwieldy  to  be  managed  by  any  but  the  most  expert  analysts. 

A  simple  extrapolation  of  current  trends  shows  that  this  situation  could  change  with¬ 
in  the  next  five  years,  and  certainly  within  a  decade.  If  we  once  pass  the  "manageability" 
barrier  a  whole  new  (for  aerospace)  concept  of  structural  modelling  becomes  feasible.  In 
the  past  it  has  always  been  necessary  to  use  a  considerable  degree  of  skill  and  judgment 
in  deciding  how  (or  even  whether)  to  represent  fine  detail  within  the  bounds  of  individual 
elements.  Skilful  modelling  can  be  the  most  time-consuming  of  all  data-preparation 
processes;  unskilled  modelling  can  destroy  the  value  of  the  most  complex  analysis.  In 
the  limit,  assuming  that  the  hardware/software  aids  are  sufficient  to  create  and  manage 
all  the  data,  modelling  as  a  task  disappears  -  we  simply  include  every  feature  explicitly 
by  defining  a  standard  mesh  representing  its  geometry,  and  by  assigning  realistic  material 
properties  to  every  tiny  element  so  created. 

To  give  a  rough  scale  to  this  approach,  consider  the  analysis  of  a  conventional 
aircraft  wing.  In  a  typical  present  day  case  we  might  use  a  mesh  with  20  -  40  span-wise 
stations,  5-20  chord-wise  and  2-6  depthwise  for  a  single  -  pass  linear  static 
calculation,  supported  by  up  to  20  local  analyses  in  identified  problem  areas  and  as  many 
more  analyses  of  associated  components  such  as  flaps  and  control  surfaces.  The  largest 
analysis  is  typically  about  1000  nodes,  3  -  5000  degrees  of  freedom.  (Fuselage  analyses 
may  be  5  -  lo  times  this  size).  The  total  set  of  wing  analysis  tasks  could  be  lO  to  50 
times  as  large  as  the  typical  1000  node  basic  analysis.  This  is  easily  handled  on 
today's  serial-processing  computers. 

Consider  detailed  representation  in  two  stages s- 

a)  representation  of  reinforcement  (stiffeners  and/or  lamination  graduations) ,  and 
substantial  features  (access  holes,  doors,  panels,  mounting  etc.) 

b)  representation  of  individual  joints/fasteners  and  their  associated  local  structural 
changes,  individual  laminae  or  lamina  groups. 

At  level  a)  we  should  seek  a  representation  scale  which  at  least  permits  local  buckling 
to  be  investigated  in  the  main  analysis  set.  At  level  b)  we  represent  all  features  in 
sufficient  detail  to  identify  characteristic  stresses  which  can  be  associated  with 
specific  failure  criteria. 

Representation  a)  will  result  in  a  mesh  size  of  the  order  of  200  length  wise  x  50 
chord  wise  x  (on  average)  10  depthwise,  i.e.  105  nodes  -  2  orders  of  magnitude  beyond 
current  practice  and  still  needing  subsidiary  calculations  in  support. 

Representation  b)  will  demand  the  same  basic  mesh  with  refinement  to  l/10th  of  the 
linear  scale  in  discrete  regions.  This  might  mean  5-10  times  the  total  size.  We  may 
use  this  as  a  convenient  measure  of  total  analysis  content  in  both  cases. 

One-off  analyses  of  up  to  5  x  105  d.o.f.  have  been  performed,  using  multi-level  sub¬ 
structuring,  on  present  day  computers  so  there  is  no  question  about  the  feasibility  of 
analyses  up  to  5  x  106  d.o.f.  using  the  best  Class  6  machines.  For  automated  modelling 
we  shall  need  computer-based  solid  geometry  to  the  same  level  of  detail  and  it  may  be 
geometry  generation,  storage  and  manipulation  which  will  determine  computer  capacity. 

The  hardware/software  advances  expected  in  the  next  10  years  should  certainly  bring  the 
lofi-107  d.o.f.  super-analysis  into  the  practical  range,  if  we  decide  that  this  is  what  we 
need  and  develop  the  tools  to  achieve  the  goal. 

At  the  cost  of  a  very  large  development  effort  to  produce  a  balanced  set  of  tools  for 
generation,  handling,  storage  and  display  of  the  vast  amounts  of  data  -  but  with  the 
prospect  of  greatly  reduced  time  and  effort  in  analysis  preparation  and  interpretation  -  a 
totally  different  picture  of  structural  computing  demand  would  emerge.  This  scenario 
demands  high  usage  of  the  best  foreseeable  computing  equipment  -  the  whole  philosophy 
collapses  without  the  quantum  leap. 

3.  ASSISTED  UTILISATION  OF  STRUCTURAL  COMPUTING  TOOLS 

It  is  a  banal  truth  that  a  structural  expert  using  simple  and  modest  computing 
tools  could  always  out-perform  an  idiot  using  the  best,  (even  idiot  proof)  available 
tools.  The  ingrained  appreciation  of  "what  actually  matters"  and  the  ability  to  read 
across  significant  information  between  global  and  local  analyses,  omitting  the  irrelevant, 
adds  an  extra  dimension  to  the  potential  effectiveness  of  simple  tools.  It  is  equally 
true  that  people  of  the  calibre  needed  to  achieve  this  top  level  performance  do  not,  and 
cannot  be  persuaded  to,  do  such  a  job  for  any  length  of  time.  We  do  not  think  it 
feasible  to  postulate  'genius-level'  performance  from  the  day-to-day  analysts  as  a  viable 
alternative  to  the  super-analysis  previously  considered. 

However  an  improved,  and  self-improving  level  of  performance  can  potentially  be 
obtained  from  proficient,  but  non-expert  analysts  if  we  Introduce  expert-systems  concepts 
into  data  preparation  and  output  interpretation  stages  of  finite  element  analysis.  At 
present,  we  are  only  learning  the  first  principles  of  constructing  expert  systems  -  how 
to  capture  the  knowledge  of  experts,  store  it  and  make  it  accessible  to  users  at  the  time 
of  analysis  preparation  or  interpretation.  The  tools  we  are  using  are  clumsy  and 
incomplete  and  it  has  not  yet  been  shown  to  be  feasible  to  construct  a  really  large  and 
complex  system  such  as  might  be  required  to  provide  a  general  purpose,  "intelligent" 
front  end  to  a  large  finite  element  analysis  suite.  However,  we  have  reached  the  stage 
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where  individual  steps  along  that  route  have  been  taken.  A  prototype  system  SACON  (2) 
has  been  available  for  some  years  from  the  U.S.A.,  it  is  very  limited  in  the  problems 
which  it  can  address:  concerning  itself  with  the  type  of  analysis  to  be  performed  rather 
than  with  the  larger  problems  of  modelling  and  data  preparation.  Two  U.K.  system  studies 
are  tackling  these  problem  areas.  NASCON  (3)  is  being  developed  to  aid  the  inexperienced 
user  (who  knows  what  problem  he  wishes  to  solve)  to  select  the  appropriate  data  entry  and 
solution  facilities  for  solving  his  problem  using  NASTRAN,  with  explanation  and  help 
tailored  to  his  needs .  Our  own  FEASA  project  is  studying  the  problem  of  helping  the  user 
who  is  unfamiliar  with  the  details  of  finite  element  analysis  to  formulate  his  "real  world" 
problem  properly  and  make  appropriate  decisions  concerning  mesh  shape  and  size,  element 
type  selection,  solution  procedures,  constraint  representation  etc.  -  the  first  level 
decisions  in  modelling. 

These  studies  lead  to  the  firm  conclusion  that  the  knowledge  concerned  can  be  trans¬ 
ferred  by  this  route  -  but  with  some  difficulty  in  its  formalisation  and  at  a  high  cost 
in  the  size  and  complexity  of  a  practical  computing  system.  For  example,  the  FEASA 
system  already  involves  over  10O0  actions  and  derivations  (the  entitles  used  in  its  SAVOIR 
shell  system  for  describing  knowledge)  and  uses  a  large  part  of  the  capacity  of  a  VAX 
11/750 with  barely  adequate  response  time.  To  perform  a  useful  general  purpose  job  it 
would  need  to  be  expanded  to  about  three  times  its  present  size.  At  this  size,  it  might 
only  be  addressing  about  a  quarter  of  the  user  interface  problems  involved  in  a  simple 
linear  static  analysis  and  less  than  10%  of  those  facing  all  users  of  a  large  FE  system. 

The  computing  capacity  to  support  an  "intelligent  interface"  with  a  large  FE  system  with 
many  simultaneous  users  is  thus  certain  to  be  significant  and  may  be  very  large.  Further¬ 
more,  this  capacity  is  being  deployed  in  highly  interactive  dialogue  with  users  and  will 
rapidly  clog  up  communications  if  the  computing  power  is  moved  far  from  the  user. 

Present  day  technology  suggests  that  the  ideal  way  to  introduce  intelligent  interface 
systems  is  to  run  them  on  high  power  super-micro  work  stations  with  multi-windowing.  The 
support  system,  using  text  and  elementary  sketch-pad  graphics  is  displayed  alongside,  and 
shares  the  physical  problem  data  base  with,  the  input  data  and/or  the  solution  output. 
Solution  of  the  analysis  can  be  handled  on  the  micro  itself,  on  a  departmental,  large  mini 
or  on  a  corporate  large  mainframe,  according  to  the  job  size.  The  pace  of  development  of 
packaged  power  suggests  that  the  departmental  mini-computer  may  become  redundant  in  the 
evolution  of  an  integrated  corporate  computing  system. 

The  relevance  of  this  discourse  to  large-scale  computing,  in  the  narrow  sense,  may  not 
be  immediately  obvious;  but  the  provision  of  expertise  at  the  user's  disposal  at  the  work 
place  is  certain  to  build  up  a  more  interesting  and  involved  dialogue  which  will  probably 
lead  to  an  interest  in  the  problem  being  solved  and  a  desire,  on  the  user's  part,  to  be  in 
control  of  the  modelling  and  interpretation  rather  than  a  reliance  on  remote  number  crunch¬ 
ing.  It  could  thus  be  seen  as  a  "human  alternative"  to  the  remote  solution,  whose  very 
vastness  takes  it  out  of  the  user's  hands.  It  is  not,  however,  necessarily  such  an 
alternative,  since  the  expert  interface  is  as  usable  for  organisation  of  the  large  problem 
as  it  is  for  intelligent  modelling  at  the  smaller  scale.  It  might  lead  to  a  different 
view  of  the  disposition  of  computing  resources,  requiring  more  power  at  the  user's  elbow 
and  probably  less  at  the  centre;  it  therefore  affects  priorities,  investment  and  develop¬ 
ment  funding. 

The  introduction  of  the  expert  systems  concept  into  structural  analysis  changes  the 
black-and-white  nature  of  the  decision  to  go  for  explicit  detailed  modelling  and  the 
absolute  necessity  for  vast  computing  power  which  goes  with  that  decision.  It  also  helps 
arrest  the  spiral  descent  into  mediocrity  on  the  analyst's  part:  the  self-fulfilling 
prophecy  which  is  fundamental  to  the  case  for  ultra-fine  detail. 

4.  EFFECTS  ON  COMPUTING  REQUIREMENTS 

Combining  the  above  considerations  with  the  earlier  extrapolations  of  structural 
computing  needs  suggests  a  more  positive  requirement  for  order-of-magnitude  increases  in 
computing  power  than  have  previously  been  suggested.  Table  1  provides  a  simple  summary. 
There  is  an  increasing  trend  to  use  computer-based  analysis,  supported  by  detailed  analysis 
and  testing  as  an  alternative  route  to  airworthiness  clearance  in  place  of  full  scale 
testing.  The  requirement  for  increased  confidence  in  the  accuracy  and  reliability  of 
analysis  is  growing.  At  the  same  time,  the  typical  analysis  user  is  likely  to  be  a 
•slick'  computer  key-board  practitioner  and  a  reasonably  trained  structural  engineer,  but 
is  most  unlikely  to  be  expert  in  the  fundamentals  of  finite  element  analysis. 

Me  see  the  provision  of  tools  to  support  the  analyst,  either  by  explicit  modelling  and 
vast  numerical  simulation  or  by  expert  assistance  at  data  preparation  and  interpretation 
time,  not  as  optional  'frills'  but  as  essential  elements  in  maintaining  standards  of 
Integrity  and  improving  user  productivity.  In  the  writer's  judgment,  the  provision  of  the 
self-tutoring  expert  assistant  is  marginally  the  more  necessary,  because  it  is  safer  to 
ensure  improved  understanding  of  the  analysis  task  than  to  rely  on  a  process  which  largely 
by-passes  human  judgment. 

Developing  the  reliable  software  needed  to  support  both  approaches  is  a  substantial 
task  requiring  the  Involvement  of  aircraft  industry  finite  element  specialists  as  well  as 
analyst  programmers  (who  need  not  come  from  the  industry  itself) .  We  see  a  need,  in  both 
cases,  for  software  tailored  to  the  special  needs  of  the  aircraft  Industry  but  strongly 
support  the  use  of  more  general-purpose  software  'tool  kits'  and  data  base  management 
systems  in  order  to  produce  compatible  systems  by  design  rather  than  by  adaptation. 
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Software  development  timescales  for  both  types  of  system  are  similars-  3-5  years  for 
evolution  of  reliable  tools  for  general  design  use.  This  suggests  that  we  should  aim  to 
develop  from  our  present  style  of  computing  (large  mainframes  plus  distributed,  functionally 
specialised  minis  plus  more-or-less  intelligent  terminals) ,  via  access  to  a  large  super¬ 
computer  for  system  development,  towards  an  eventual  system  in  v.’hich  a  large  central  number¬ 
crunching  and  data  management  facility  is  coupled  as  directly  as  possible  to  highly 
intelligent  and  functionally  specialised  workstations.  Our  ideal  solution  will  provide 
both  kinds  of  computing  environment:  the  total  geometrical/numerical  structural  modeller 
and  the  expert-assisted  interface. 


FIG.  1 


IDEALISED  COMPANY  COMPUTING  FACILITY 


The  ideal  computer  installation  suggested  in  the  grossly  simplified  figure  1  is  not 
unlike  today's  arrangements  except  that  the  role  of  the  specialised  mini  computer  network 
is  replaced  by  more  centralisation  of  corporate  data  management  and  CPU  power  and  very 
powerful  microcomputers  in  small  local  area  networks.  We  see  the  timescale  for  migration 
to  this  type  of  facility  as  about  5  years,  i.e.  aiming  for  1990,  dictated  largely  by 
software;  with  an  interim  period,  starting  in  1986  at  the  latest,  where  access  to  a 
software-compatible  super-computer  is  necessary. 
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TABLE  1 


STRUCTURAL  COMPUTING  REQUIREMENTS  SUMMARY 


For  a  large  aircraft  company  by  1990 


Type  of  Capability 

Scale  Indication 

Urgency  of  Requirement 

Basic  finite  element 

analysis . 

. . .  with  ultimate  data 

Models  and  solutions  up  to 
107  d.o.f.  (102  -  103  x 

IBM  308 IK  capacity) 

Desirable  for  productivity 
through  full  automation 

. . .  Detailed  solid  modell¬ 
ing  of  airframe 
geometry . 

...  with  design  links  to.^\ 

_ _ s* 

. . .  Optimisation 

Detail  definition  at  approx. 
-4 

lo  x  linear  dimensions  in 

3-d  solid  model 

Essential  as  accompaniment 

to  the  above 

4  5 

lo  to  10  variables 

100  simultaneous  design 

conditions 

Highly  desirable  for 

Competitive  edge 

Non  linear  analysis 

lO3  -  104  d.o.f. 

102  -  103  iterations 

Desirable 

Intelligent  front-end 

At  least  VAX  11/780  power 
dedicated  to  support  each 
6-10  users  -  sharing  FE 
analysis  database 

Highly  desirable/necessary 
for  safe  use  of  complex 
'black  box'  systems 
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SUMMARY 

Significant  investments  in  computer  software  and  hardware  support  engineering  design, 
analysis,  and  synthesis  functions.  Updating  these  investments  to  accommodate  changes  in 
hardware  and  software  is  a  major  concern  to  engineering. 

The  forces  shaping  the  engineering  computing  environment  in  the  next  ten  years  will 
be  dynamic  and  multifaceted.  This  paper  discusses  the  role  of  the  more  prominent  forces 
and  suggests  ways  to  focus  these  forces  on  satisfying  engineering  computing  needs. 

LIST  OF  ACRONYMS  AND  DEFINITIONS 


AT&T 

bit 

byte 

CAD/CAM 

CDC 

cpu 

DEC 

DG 

FAMAS 
Giga  . . . 
IBM 

IBM  PC 
i/o 

Mega  . . . 

MegaFLOPS 

M680xx 

MC68020 

Mhz 

MIPS 

NS32032 

NASA 

NASTRAN 

UNIX 


INTRODUCTION 


American  Telephone  and  Telegraph 
a  binary  element/ line/pin 
contains  eight  bits 

computer  aided  design/computer  aided  manufacturing 

Control  Data  Corporation 

central  processing  unit 

Digital  Equipment  Corporation 

Data  General  Corporation 

Lockheed's  matrix  data  based  computing  system  for  aeroelastic  analysis 

-10**9  . . .  such  as  in  Gbytes  or  gigabytes 

International  Business  Machines  Corporation 

IBM  personal  computer  which  uses  Intel  8088 

input/output 

10**6  ...  such  as  in  megabytes  or  megabits 
millions  floating  point  operations  per  second 
Motorola's  complete  32-bit  microprocessor  family 
Motorola's  16/32-bit  microprocessor  family 

Megahertz,  usually  the  clock  frequency  units  of  a  microprocessor  chip 
millions  of  instructions  per  second 

National  Semiconductor  complete  32-bit  microprocessor 

National  Aeronautics  and  Space  Administration 

structural  finite  element  program  developed  by  NASA 

a  multiuser,  multitasking  operating  system;  is  a  trademark  of  AT&T 

Bell  Laboratories 


Computer  technology  today  retains  many  aspects  of  the  pioneer  spirit  and  the  excite¬ 
ment  of  an  industry  whose  horizons  are  unlimited. 

While  the  pioneering  excitement  continues  today  in  artificial  intelligence,  robotics, 
speech  recognition,  and  real-time  processing,  an  equally  enthusiastic  segment  of  the  aero¬ 
space  community  desires  to  integrate  matured  engineering  design  processes  into  a  cost- 
effective,  computer-aided  design  tool.  Significant  investments  in  computer  software  and 
hardware  support  engineering  design,  analysis,  and  synthesis  functions.  Updating  these 
investments  to  accommodate  changes  in  hardware  and  software  is  a  major  concern  to 
engineering. 

Of  equal  importance  is  the  integration  of  advanced  design  capabilities  such  as  non¬ 
linear  aerodynamic-structural  interaction  codes,  structural  sizing  with  active  controls, 
and  battle  damage  tolerant  system  analyses  into  the  design  process.  The  goal  is  to 
increase  the  engineering  design  capability  while  controlling  the  cost  of  improving  the 
computing  environment. 

The  forces  shaping  the  engineering  computing  environment  in  the  next  ten  years  will 
be  dynamic  and  multifaceted.  The  objectives  of  this  paper  are  to  identify  and  understand 
these  forces,  to  convert  perceived  liabilities  into  assets,  and  to  focus  hardware  and 
software  advancements  toward  satisfying  future  engineering  computing  needs. 

PROBLEM  DEFINITION 

One  of  the  most  controversial  subjects  in  engineering  is  the  apparent  uncontrolled 
increases  in  engineering  computing  costs  associated  with  high-technology  designs.  The 
controversy  starts  with  identification  of  the  cause  of  the  high  computing  costs. 

In  a  hypothetical  structural  analysis  and  synthesis  effort,  it  can  be  argued  that  a 
finite  element  structural  model  with  twenty  thousand  degrees  of  freedom  and  the  associated 
two  thousand  load  cases  is  one  of  the  principle  causes  of  the  increases  in  computing 

. .  .  ■»  -  -  -  .  . 
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costs.  In  defense,  the  structural  analyst  points  to  the  design  requirements  for  an 
accurate  representation  of  the  physical  system  demanded  by  the  structural  guarantees  which 
are  in  the  contract  with  the  customer. 

The  analyst  argues  that  if  the  computing  environment  were  improved,  the  total  cost 
of  the  design  would  decrease.  He  identifies  the  computing  equipment  and  the  software  as 
being  the  primary  problem  areas. 

The  computing  division  counters  that  it  is  given  a  fixed  budget  to  service  engineering 
computing  needs,  and  that  computing  technology  is  changing  so  fast  that  equipment  changes 
must  be  optimized  to  minimize  computing  costs. 

The  project  program  manager  hears  words  such  as  synergisms  and  integrated  design 
efforts.  The  tradeoff  between  fighting  for  a  step  increase  in  computing  capacity  to 
translate  these  advanced  concepts  into  actual  practice,  and  staying  with  past  design  con¬ 
cepts  and  available  computing  capacity  is  a  difficult  no-win  decision.  This  first  option 
will  incur  a  step  increase  in  cash-flow,  while  the  second  option  will  probably  incur 
schedule  slipping  and  design  requirement  compromises. 

There  are  no  simple  solutions  to  the  above  conflict  of  computer  resource  allocations. 

The  following  sections  will  discuss  the  forces  that  have  formed  the  engineering  computing 
environment  during  the  past  twenty  years.  An  approach  to  satisfying  future  engineering 
computing  needs  will  then  be  proposed  within  the  constraints  implied  by  the  understanding 
of  the  dominant  forces  governing  the  future  hardware  and  software  technology  developments. 

i * 

COMPUTING  ENVIRONMENT 
User  Profile 


The  engineering  computing  environment  is  a  complex  interrelationship  of  user  access 

to: 

1)  interactive  processing  for  data  preparation  and  review  of  output  data 

2)  cpu  and  i/o  engines 

3)  flexible  and  comprehensive  computer  operating  systems 

4)  print /plot /microfiche/etc.  forms  of  output 

5)  database  management  systems 

6)  proven  computer  programs 

7)  high-level  system's  integrator 

8)  software  development  and  software  support 

9)  documentation 

10)  capital  resources  to  affort  items  1  through  9. 

An  inadequate  computing  environment  is  equivalent  to  an  ill-defined  mathematical  state¬ 
ment.  To  the  engineer,  both  are  barriers  to  a  solution.  In  a  deficient  computing  envi¬ 
ronment,  the  engineer  will  go  beyond  the  user  role  and  do  whatever  his  organization  will 
permit  to  resolve  the  deficiency;  for  example,  develop  software,  buy  equipment,  buy 
timeshare  services,  etc. 

Computers  and  Organizations 

The  computer  is  the  modern  day  two-edged  sword.  This  high  technology  tool  can  either 
increase  the  organization's  productivity  or  lead  the  organization  into  serious  difficul¬ 
ties.  Sometimes  a  manager  credits  the  computer  with  doing  both  simultaneously. 

Computers  are  a  vital  resource  in  a  technology- based  organization.  Those  who  control 
this  resource  are  close  to  inter-company  power  struggles.  Computing  resources,  therefore, 
are  the  favorite  food  of  empire  builderB,  cost  cutters,  endless  justification  requesters, 
buck  passers,  user  tax  collectors,  soft-dollar  versus  hard-dollar  debaters,  and  tax  write 
off  pushers.  Computer  facilities  create  internal  activities  apart  from  the  primary  goals 
of  the  organization.  In  most  technology-based  organizations,  allocation  of  computer 
resources  resembles  more  an  art  form  than  a  standard  business  practice. 

Organizations  classify  computers  both  as  utilities,  such  as  telephones,  and  as  luxu¬ 
ries,  such  as  excessive  wage  demands.  Merging  the  requirements  of  the  "the  bit  and  byte" 
user,  the  number-cruncher  user,  the  business  user,  the  computer-knowledgeable  user,  the 
interactive  user,  the  graphics  user,  and  the  operating  system  manipulator  user  into  one 
facility  challenges  the  imagination  of  the  most  optimistic  neophyte.  What  is  a  luxury 
to  one  user  is  a  necessity  to  another. 

There  are  two  purposes  for  computer  installations:  to  increase  the  productivity  of 
the  organization  and  to  provide  the  organization  with  the  capability  to  function  properly. 

Problems  arise  when  the  organization  attempts  to  keep  computer  costs  to  a  minimum  and 
ignores  the  total  coBt  of  doing  business.  Computing  facilities  grew  to  provide  technical 
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expertise  in  making  computers  and  software  serve  the  customer  in  the  most  cost-effective 
manner.  Computer  facility  organizations  became  computer  resource  power  brokers.  A  good 
data  processing  manager  shows  high  load  factors  on  the  computing  machines. 

How  the  computer  facility  policies  affect  the  overall  cost  of  doing  business  is 
either  ignored  or  considered  too  complex  to  include  in  facility  cost  tradeoff  studies. 
These  barriers  are  coming  down,  but  the  origins  of  the  data  processing  mentality  persist. 

Competing  for  computer  resources 

A  company  generates  a  plan,  an  organization,  etc.,  to  accomplish  its  objectives. 

This  process  then  translates  the  company  resources  into  specific  objectives.  Figure  1 
shows  a  simplified  model  of  the  company  function.  If  the  company  objective  is  profit, 
the  process  uses  facilities,  material,  mojiey,  and  people  to  produce  that  economic  return. 
Included  in  the  company  objectives  are  day-to-day  operations,  such  as  general  accounting 
functions.  If  the  computer  is  in  the  resource  box  (Figure  1) ,  there  is  a  clear  competi¬ 
tion  among  different  processors  in  the  process  box  to  access  and  use  that  resource.  If 
the  computer  is  located  in  the  process  box,  then  the  competition  for  the  company  resource 
is  at  the  money  level.  The  computer  has  a  dual  personality  relative  to  the  resource  and 
process  identities  in  most  companies. 

Computing  environments  derived  from  a  least-square  fit  of  the  organizational  comput¬ 
ing  requirements  usually  cannot  satisfy  the  specific  engineering  requirements.  Mono¬ 
lithic  computer  facilities  are  tuned  to  service  the  major  customer.  Engineering  analysis 
is  rarely  a  major  customer  of  computer  resources,  if  only  because  of  the  cyclic  nature  of 
design. 

The  engineer  uses  many  tools  to  translate  an  idea  into  a  practical  reality.  A  design 
must  satisfy  the  economics  of  the  marketplace  as  well  as  the  functional  requirements.  The 
engineer  is  a  composite  of  scientist,  lawyer,  and  entrepreneur.  The  design  process 
includes  senior  judgement,  science,  planning,  designing,  manufacturing,  and  marketing. 

Whether  the  computing  environment  is  excellent  or  poor,  the  engineer  will  design. 

The  better,  more  cost  effective  design  will  depend  on  the  statement  of  work,  the  organi¬ 
zation  cost  accounting  practices,  personnel,  and  schedule  requirements.  An  enlightened 
and  informed  organization  knows  where  increased  computing  costs  will  reduce  overall  prod¬ 
uct  costs. 

On  computing  technology  developments 

Advancing  technologies  in  hardware  and  software  pose  an  unusual  dilemma  for  the  engi¬ 
neer.  If  new  engineering  design  products  are  ignored,  the  organization  becomes  techni¬ 
cally  obsolete.  If  the  new  products  are  incorporated  into  the  design  process  as  soon  as 
they  become  available,  the  organization  could  use  all  of  its  resources  merely  trying  to 
be  on  top  of  the  high-tech  curve. 

Organizations  that  have  nonchanging  technology  requirements  for  productivity 
increases,  or  high  output  of  high-end  technology  products  can  survive  these  extremes. 

The  situation  becomes  interesting  when  there  are  organizations  at  the  extremes  within  the 
same  company.  The  problem  becomes  impossible  if  the  requirements  of  many  companies  within 
the  corporate  structure  are  integrated  into  a  single  policy  or  computer-use  definition. 

The  computer  industry  makes  pronouncements  of  great  technology  break-through,  and 
expectations  rise  in  user  communities.  Translation  of  the  breakthrough  into  reliable  and 
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economical  hardware  and  software  does  not  always  happen.  Even  when  technology  barriers 
have  been  successfully  scaled  and  manufacturing  is  feasible,  marketing  may  decide  that 
the  new  product  would  undercut  one  of  the  more  profitable  lines  and  therefore  delay  its 
entry.  Projections  on  the  future  computing  environments  which  were  based  on  the  com¬ 
puter  industry  pronouncements  are  not  feasible. 

Role  of  management 

Of  all  the  issues  which  determine  the  computing  environment  for  engineering,  the  role 
of  management  is  the  most  difficult  to  evaluate.  The  user  knows  the  computing  require¬ 
ments  and  how  to  interact  with  the  computer.  Finance  wants  to  allocate  minimum  resources 
to  accomplish  the  organization's  goals.  The  computer  industry  wants  to  sell  the  newest 
computer  technology.  In  the  middle  of  the  foray  appears  management. 

R.  Richard  Ritti  in  The  Ropes  to  Skip  and  The  Ropes  to  Know,  says  that  the  fundamen¬ 
tal  truth  known  to  seasoned  managers  is  the  "...best  decision  is  no  decision  at  all.” 

When  the  manager  has  complete  information,  the  "...task  is  simply  to  pick  the  best  alter¬ 
native."  This  good  decision  is  no  decision  at  all.  The  second  situation  is  when  the 
"...the  possible  outcomes  are  known  with  probabilities  attached  to  these  outcomes." 

Again,  the  manager  picks  the  best  one,  usually  the  one  with  the  minimum  risks  and  the 
maximum  benefits.  Finally  there  is  that  situation  which  is  filled  with  uncertainty.  The 
manager's  gameplan,  then,  is  to  find  someone  to  "...take  the  risk  while  making  sure  that 
it  is  he  who  stands  to  gain."  The  manager  "...will  leave  the  decisions  to  someone  else." 

The  acquisition  of  computer  resources  must  involve  one  of  the  best  played  games  at 
making  no  decisions  because  of  the  uncertainties  and  because  of  the  large  investment  the 
organization  must  make.  This  is  a  major  factor  to  address  when  assessing  the  direction 
of  future  computing  environment.  Contributing  to  the  uncertainties  is  the  lack  of  mana- 
erial  tools  to  accurately  predict  computing  needs  in  terms  of  the  organization's  stra¬ 
tegic  goals  and  the  effect  of  reducing  the  total  cost  of  doing  business. 

Another  consideration  is  the  time  required  to  develop  a  top  engineering  manager 
versus  the  time  required  for  the  computer  industry  to  bring  to  the  market  hardware  or 
software  which  radically  changes  the  computing  environment.  A  top  manager  today  who  was 
fortunate  to  have  had  any  computer  hands-on  experience  was  probably  working  with  a  deck 
of  input  cards  and  magnetic  tapes. 

What  are  the  top  engineering  managers'  perspectives  on  attaching  monitors,  relational 
database  managers,  front-end  computers,  terminals  on  the  desk,  access  to  printers  and 
plotters,  and  computing  power  measured  in  XOs  of  megaFLOPS  (millions  floating  point  oper¬ 
ations  per  second) ?  How  do  these  topics  relate  to  the  technology  competitiveness  and 
productivity  within  engineering?  How  do  these  topics  relate  to  keeping  within  budget 
and  schedule  commitments? 

COMPUTER  DEVELOPMENT  FORCES 

From  humble  beginnings 

In  1958,  the  author  visited  the  germanium  diode  computer  installation  at  Point  Mugu 
Naval  Air  Station.  A  special  vault  isolated  the  computer  from  exterior  electromagnetic 
interference  and  kept  the  installation  within  1  degree  of  the  designed  operating  tempera¬ 
ture.  An  elaborate  environmental  control  system  monitored  the  humidity  as  well  as  the 
temperature.  Fire  alarm  bells  rang  when  tolerances  were  exceeded. 

These  first  digital  computers  were  temperamental  and  extremely  limited  in  computing 
power;  however,  they  provided  important  operational  data  and  user  interface  experience. 
Universities  used  these  first-generation  computers  to  help  develop  courses  in  computer 
science.  Today,  the  universities  are  following  a  similar  path  with  the  first  CAD/CAM 
computer  systems. 

Structural  design  numerical  problems  were  probably  one  of  the  first  uses  of  commer¬ 
cially  available  digital  computers  such  as  the  IBM  704.  These  first  machines  had  limited 
computational  capabilities:  no  input/output  devices  except  for  a  teletype  system  termi¬ 
nal,  a  card  reader,  a  card  output  punch,  and  a  printer.  They  were  under  engineering  con¬ 
trol,  and  the  first  operators  were  engineers.  While  the  machines  were  slow  relative  to 
current  computers  and  difficult  to  keep  running,  their  impact  on  engineering  problem 
solving  capability  were  felt  immediately.  The  computer  performed  numerical  computations 
in  one  day  that  took  weeks  for  a  team  of  people  on  mechanical  calculators. 

The  key  element  in  mathematical  models  for  structural  and  dynamic  analyses  is  the 
number  of  degrees  of  freedom  (DOF)  which  is  permitted  in  the  problem  formulation.  The 
first  digital  computers,  when  compared  to  a  team  of  people  on  mechanical  calculators, 
were  cost  effective,  with  increases  in  DOF  of  two  to  three  times.  The  digital  computer 
economics  for  these  types  of  engineering  problems  initiated  the  trend  of  justifying 
higher  computer  unit  pricing  for  lower  solution  costs  per  problem. 

The  performance  to  price  ratios  quoted  by  computer  manufacturers  is  today  a  continu¬ 
ing  source  of  conflict  for  engineering  management.  During  low  design  activity,  the  num¬ 
ber  of  problems  is  small  and  the  cost  per  solution  is  large.  During  periods  of  high 
design  activity,  the  cost  per  solution  is  low.  However,  the  high  computer  turn-around 
times  can  stretch  out  schedules  and  cause  high  total  task  costs.  To  engineering  manage¬ 
ment,  computers  are  a  no-win  proposition. 


Today,  the  digital  computer  has  made  major  inroads  into  banking,  manufacturing,  air¬ 
line  reservations,  payroll  and  accounting,  artificial  intelligence,  expert  systems,  word 


3-5 


processing,  defense  systems,  robotics,  energy  distribution  networks,  the  charge  card 
industry,  online  inventory  and  control,  the  stock  market,  telecommunications,  worksta¬ 
tions,  and  all  aspects  of  engineering  design  and  testing.  Digital  computers  are  found 
in  security  systems,  aircraft  and  spacecraft  flight  control  systems,  tanks,  cars,  trucks, 
trains,  missiles,  ships,  appliances,  etc. 

The  computer  today  influences  every  aspect  of  a  company/ government  installation,  not 
only  in  high-end  technology  operations,  but  in  day-to-day  functions  such  as  word  process¬ 
ing  and  information  management.  The  trend  today  is  real-time  applications  for  planning, 
budgeting,  and  tracking  of  project  schedules  and  goals.  The  computer,  which  began  servic¬ 
ing  exclusively  engineering  computing  requirements,  is  providing  a  general  utility  to  the 
whole  organization. 

Computer  Marketing  Forces 

The  computer  industry  is  continually  having  highs  and  lows.  Companies  that  achieved 
industry  leadership  status  during  their  existence  have  an  average  life  span  of  less  than 
ten  years.  A  five-year  old  company,  from  initial  product  development  to  100+  million 
sales,  talks  about  60  percent  of  the  market  penetration  and  contrasts  its  mature  company 
with  the  new  upstarts.  At  the  other  end  of  the  spectrum  are  the  market  pacers,  who  see 
market  penetration  and  market  share  as  the  primary  motivation  to  product  developments. 

If  the  specialized  customers'  needs  are  served  also,  it  is  accidentally.  The  market 
pacers  are  experts  at  making  the  customer  feel  privileged  to  be  served  by  them.  Their 
products  are  vehicles  for  their  marketing  and  sales  engines.  If  a  new  market  segment 
develops,  market  pacers  step  in  and  liquidate  the  assets.  The  market  pacers  rarely  make 
hardware  improvements  not  required  by  at  least  80  percent  of  their  customer  base. 

In  a  recent  report,  Paine  Webber  Inc.  analyst  Jonathan  M.  Fram  shows  that  a  $200- 
billion-per-year ,  computer-related  industry  market  exists  in  just  three  of  its  many  facets, 
namely  a  $90-billion  existing  data  processing  industry,  an  $85-billion  telecommunications 
industry,  and  a  $25-billion  workstation  industry.  PC  RETAILING  reports  that  the  personal 
computer  industry  alone  is  $30  billion.  The  computer  industry  is  the  nation's  fourth 
largest  advertiser,  spending  an  estimated  $3.1  billion  each  year. 

Meanwhile,  the  hallmark  of  the  engineering  numerical  processors,  the  Cray  and  CDC  205 
(the  so-called  supercomputers) ,  market  share  is  about  20  machines  per  year  at  a  cost  of 
$20  million  for  each  installation.  This  $400  million  market  is  pale  when  compared  to  the 
workstation  market  alone.  How  is  it  that  the  engineering-related  numerical  calculations 
which  first  heralded  the  power  of  the  computer  have  been  reduced  to  an  insignificant  foot¬ 
note  in  the  computer-market  sales  activity?  Productivity  gains  in  areas  other  than  large- 
scale  engineering  problems  appear  to  be  the  market  forces  that  have  the  big  blue  and  other 
computer  manufacturers  satisfying  the  customers'  needs.  While  large-scale  numerical 
problems  were  at  one  time  the  technological  force  for  computer  development,  it  is  not  so 
today.  It  is  no  wonder  that  engineering  finds  itself  on  business  machines. 

Upward  push 

The  most  dramatic  elements  in  computer  technology  development  have  been  in  the  micro¬ 
processor  field.  Five  years  ago,  the  computer  market  was  segmented  into  the  following 
groups: 


Groups 


o  MAINFRAMES 

super  number  cruncher,  (CRAY,  CDC) 
number  cruncher,  (CDC,  Univac) 
transaction  machine,  (IBM) 

o  OTHERS 


32  bit  processor,  (VAX) 

16  bit  processor,  (DG-Nova) 
8  bit  processor 


Subgroups 


supercomputers 
mainframe  computers 


supermini  computer 

minicomputer 

microcomputer 


Today,  the  16-bit  processor  personal  computer  replaces  the  8-bit  processor  microcomputer 
with  8-bit  and  16-bit  data  paths.  An  Intel  8088  16-bit  processor  running  at  8  Mhz  with 
8087  co-processors  is  only  10  times  slower  than  the  VAX  11/780  supermini  computer  for  a 
single  precision  floating  point  intensive  problem. 


The  M68010  processor  is  a  32-bit  internal  processor  with  a  16-bit  data  path  and 
24-bit  address  capability.  This  processor  is  running  at  12  Mhz  in  many  computer  systems. 
Finally,  a  number  of  full  32-bit  processors  such  as  the  MC68020  and  the  NS32032  are  cur¬ 
rently  being  implemented  on  full  32-bit  backplane.  These  processors  will  run  at  clock 
frequencies  up  to  20  Mhz  and  will  have  numerical  co-processors. 

Traditional  mini  and  supermini  markets  are  experiencing  pressure  from  the  microcom¬ 
puter  developments.  The  supermini  suppliers,  therefore,  are  upgrading  their  performance- 
to-price  ratios  to  where  their  software  edge  will  keep  the  supermicro  developments  at 
bay.  Supermicros  are  microcomputers  which  exceed  0.8  MIPS  computing  power.  A  sign  that 
the  supermini  vendors  are  leaving  the  1  to  3  MIPS  machine  market  to  the  supermicros  is 
evident  in  the  recent  announcements  from  the  supermini  vendors. 
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DEC  upgraded  its  top-of-the-line  VAX  to  compete  with  the  traditional  mainframe  mar¬ 
ket.  The  top-of-the-line  VAX  8600  supermini  computer  replaces  the  7-year  old  VAX  11/780. 
DEC  is  offering  the  8600  with  4M  bytes  of  memory  for  2.4  times  the  cost  of  the  11/780 
with  2M  bytes  of  memory.  However,  the  8600  system  performance  can  be  as  much  as  4.2  times 
that  of  the  11/780.  The  manager  of  the  VAX  marketing  group  contends  that  a  VAX  cluster 
comprising  seven  8600s,  one  11/780  and  40G  bytes  of  disk  storage  can  equal  the  performance 
of  the  IBM  3084  high-end  mainframe  for  33  percent  less  cost.  This  appears  to  be  true  if 
no  application  running  on  the  system  exceeds  the  bounds  on  any  single  processor  within 
that  cluster. 

The  introduction  of  the  8600  in  the  3-5  MIPS  offering  will  start  the  game  of  leapfrog 
between  DEC  and  its  major  competitors  —  Data  General,  Prime  Computer,  Perkin-Elmer , 
Harris,  Gould,  and  Hewlett-Packard.  The  goal  of  this  game  is  to  produce  a  general-purpose 
supermini  offering  8  to  10  MIPS  by  1988  —  1990.  The  offerings  in  1995  by  extrapolation 
could  be  10  to  15  MIPS.  The  time  has  come  for  a  new  name,  mainframe-minis. 

While  DEC  is  emphasizing  the  corporate  data  processing  market.  Convex  Computer  Cor¬ 
poration  (Dallas)  is  beta  testing  a  mini  supercomputer  that  integrates  both  scalar  and 
vector  processing.  The  computer  is  said  to  run  VAX  Fortran  applications  essentially 
unchanged  and  yet  offers  one  quarter  the  processing  power  of  a  Cray  at  one  fifth  the 
price.  This  would  put  it  in  the  8600  price  class  with  more  numerical  computing  power  than 
the  IBM  3083. 


Meanwhile,  DEC  is  facing  increasing  pressure  from  IBM's  43XX  and  the  3083-CX,  which 
is  the  308X-family ' s  entry-level  processor.  IBM  has  positioned  its  products  to  compete 
with  the  superminis  offerings  in  performance  and  price. 


Focussing  on  productivity 


The  computing  power  of  the  microprocessor  made  possible  the  packaging  of  the  numeri¬ 
cal  computing  power  of  the  VAX  11-780  into  a  dedicated  single-user  machine.  While  per- 
formance-to-price  ratios  were  a  factor,  a  single-user  machine  focussed  for  the  first  time 
on  user  productivity. 


Engineering  recognizes  that  the  total  project  cost  is  the  governing  factor  to  control. 
Single-user  machine  costs  are  well-defined.  It  does  not  require  a  systems  support  group, 
on-side  hardware  maintenance  group,  special  environmental  support  such  as  air-conditioning 
and  noise  isolation,  and  complex  user  use  algorithms  for  accounting  purposes.  It  provides 
a  nondegradable  machine  response,  tailoring  of  the  machine  function  with  minimum  conten¬ 
tion  with  other  users,  portability,  and  powerful  graphics  capabilities.  The  application 
of  this  technology  made  the  engineering  workstation  industry  into  a  major  marketing  force 
in  less  than  five  years. 


The  shrinkinq 


The  computer-chip  industry  produces  a  large  variety  of  products,  including  micropro¬ 
cessors,  memories,  memory  controllers,  memory  management  units,  floating  point  units, 
timing  control  units,  address  latch  buffers,  data  buffers,  and  general  support  chips. 

The  dominant  player  among  these  chips  is  the  microprocessor  which  usually  has  a  strong 
association  with  product  line  using  chip,  such  as  the  Intel  8088  in  the  IBM  PC. 


The  microprocessor  comes  in  a  number  of  models,  each  sporting  different  numbers  of 
data,  address,  accumulator,  and  processing  bits.  The  power  of  the  microprocessor  is 
measured  by  the  chip  clock  frequency  and  the  number  of  clock  cycles  required  to  complete 
a  particular  function.  Some  models  have  floating  point  co-processors  to  speed  floating¬ 
point  calculations,  symmetrical  instruction  architecture,  instruction  prefetch,  virtual 
memory,  etc.  They  offer  the  system  integrator  a  variety  of  solutions  for  assembling  com¬ 
puter  systems.  Each  manufacturer  of  the  microprocessors  is  upgrading  its  product  line 
toward  a  full  32-bit  processor. 


Memory  chip  development  is  even  mo  .ynamic.  Three  years  ago,  computer  manufac¬ 
turers  were  concerned  with  whether  or  no.  64K  by  1  bit  chips  were  going  to  be  available 
in  commercial  quantities.  With  the  delay  of  the  64K  chips,  the  256K  by  1  bit  chips 
gained  prominence  and  are  currently  available  in  mass  quantities.  AT&T  recently  announced 
that  it  will  mass  produce  a  1  Meg  by  1  bit  chip.  While  a  chip  controller  is  not  currently 
available,  the  message  to  computer  integrators  is  clear.  Memory  costs  will  drop 
dramatically. 


An  integrated  computer  board  (one-board  computer)  with  2  Megabytes  of  on-board  mem¬ 
ory  is  available  today  in  the  Stride  400  series  machines  which  use  the  M6b000  processor 
at  10  Mhz .  If  the  1  Meg  by  1  chips  replace  the  256K  by  1  chips,  the  one-board  computer 
will  have  8  Megabytes  of  on-board  memory  with  no  wait  states. 


The  limiting  factor  in  chip  design  is  the  spacing  within  the  chip  mask  and  the  power 
available  for  driving  the  internal  circuits.  The  power  factor  is  limited  by  the  heat  dis¬ 
sipation  within  the  chip.  For  a  constant  power  factor  within  the  chip,  the  speed  of  the 
circuits  is  a  function  of  the  mask  spacing  within  the  chip. 


Six  years  ago,  the  4-Mhz  Z80  chip  made  a  significant  impact  on  the  8-bit  processor 
market  when  the  clock  frequency  standard  at  that  time  was  1  to  2  Mhz.  Today,  the  market 
is  preparing  for  the  full  32-bit  internal  and  external  architecture,  such  as  the  MC68020, 
Intel's  80386,  NC32032  and  Z80032.  Major  advances  in  chip  masking  (down  to  2  microns  for 
the  MC68020)  made  possible  both  the  increase  in  chip  complexity  and  the  increase  in  pro¬ 
cessor  clock  frequencies. 


With  DOD  asking  qualified  vendors  to  look  into  the  1.25  micron  technology,  a  main¬ 
frame  desktop  calculator  running  at  clock  frequency  of  40  Mhz  with  20  megabytes  of  memory 
is  a  distinct  possibility  by  1995  if  a  commercial  market  is  sufficiently  strong  in  that 
area. 


The  traditional  technologies  of  chip  designers  are  N-channel  metal-oxide  semiconduc¬ 
tor  (NMOS)  and  XMOS,  because  of  their  high  performance  level.  These  devices,  however, 
are  power-hungry  and  require  significant  amounts  of  cooling. 

Complementary  metal-oxide  semiconductor  (CMOS)  technology  requiring  less  than  one- 
tenth  the  power  of  NMOS  offers  a  good  solution  to  the  chip  heat  problems.  The  drawback 
of  CMOS  is  that  it  permits  fewer  devices  within  the  die  area,  thus  requiring  more  space 
per  board.  However,  chip  density  on  the  board  is  greater  for  CMOS  than  for  NMOS  when 
cooling  between  chips  establishes  chip  spacing  on  the  board.  A  CMOS  board  for  most  appli¬ 
cations  does  not  require  cooling  fans. 

As  the  computer  complexity  increases,  so  do  the  integrated  circuits  required  to  sup¬ 
port  microprocessors,  disc  controllers,  and  memory  controllers.  Custom  gate  arrays  elim¬ 
inate  40  to  50  integrated  circuits  in  typical  applications.  The  custom  gate  arrays  have 
clock  frequencies  up  to  25  Mhz. 

Market  pressures  make  strange  bedfellows  in  chip  technology  applications.  Emitter- 
coupled-  logic  (ECL)  based  integrated  circuits  almost  disappeared  from  consideration  by 
system  integrators  three  years  ago.  ECL  generated  too  much  heat  and  was  too  expensive 
for  all  but  mainframes  or  small  specialized  devices.  Now  with  the  push  from  microcomputers, 
the  traditional  Schottky  TTL  logic  which  was  the  basis  for  the  VAX-11/780  has  given  way 
to  the  ECL  technology,  even  in  the  face  of  the  rapidly  developing  CMOS  and  gallium  arse¬ 
nide  technologies.  Both  the  Prime  9955  and  VAX  8600  are  ECL-based  machines. 

Another  factor  in  the  shrinking  chip  is  a  new  semiconductor  technology  called  wafer- 
scale  integration  (WSI)  from  Trilogy  Systems.  While  a  typical  mainframe  now  uses  3500  to 
4000  chips,  the  WSI  machine  would  have  just  40  wafers  —  an  order  of  magnitude  reduction 
in  chip  count  which  is  difficult  to  comprehend. 


Peripherals 

The  explosive  developments  in  computer  peripherals  are  two  to  three  times  greater 
than  the  central  processor  developments.  While  a  computer  system  contains  one  central 
processor  unit,  peripherals  number  five  to  ten  items.  A  computer  system  may  include  one 
floppy  (flexible  disc)  drive,  one  hard-disc  drive,  two  printers,  one  plotter,  one  modem, 
one  terminal  or  one  monitor,  and  one  keyboard.  The  peripheral  add-on  and  update  market 
is  also  significant. 

Nothing  exemplifies  changes  in  the  peripheral  market  more  than  hard-disc  drives. 

Two  years  ago,  a  10-megabyte,  5  1/4-inch,  full-height  (3.2  inches)  Winchester  disc  drive 
sold  for  more  than  $2000.00.  This  drive's  average  access  time  was  in  excess  of  70  msec. 
Priam  Corp.  recently  announced  a  70-Megabyte  (unformatted) ,  5  1/4-inch,  half-height 
Winchester  disc  drive  with  an  average  access  time  of  25  msec.  To  equal  this  performance 
two  years  ago  would  have  required  an  8-inch,  hard-disc  drive  at  many  times  the  cost  of 
the  Priam  model  201  which  is  expected  to  sell  for  less  than  $2000.00. 

Software 


Software  capabilities  and  complexities  closely  followed  the  hardware  and  operating 
system  capabilities,  and  the  level  of  programmer  access  to  the  machine  capabilities. 

Twenty  years  ago,  the  Univac  1107  and  the  IBM  7094  computers  dominated  engineering 
problem-solving  activity.  Disc  drives  did  not  exist.  Drum  storage  devices  were  at  a 
premium  and  were  usually  reserved  for  the  operating  system.  The  computing  jobs  were  I/O 
and  cpu  bound. 

The  engineering/programmer  submitted  card  input  data.  With  the  computer,  card  reader, 
and  printer  behind  closed  doors,  access  to  rapid  turnaround  computing  was  limited  to  high- 
priority  situations.  When  access  was  granted,  the  engineer  quickly  learned  to  operate 
the  card  reader  and  to  load  tapes  on  the  tape  drives.  Under  special  circumstances,  a 
printer  was  available  as  the  job  was  running  and  the  user  could  monitor  the  job  progress 
by  leaning  over  the  printer.  If  the  user  could  think  in  this  noisy  environment,  a  new 
job  could  be  entered  into  the  computer  before  the  previous  job  was  completed. 

Even  though  access  to  the  machine  was  limited,  jobs  submitted  to  the  computer  broke 
new  ground  in  matrix  operations,  finite  element  formulations,  redundant  analysis,  and 
time  simulations.  Many  of  the  tasks  which  were  previously  the  forte  of  the  analog  devices 
rapidly  migrated  to  the  digital  computer.  As  software  developers  asked  for  more  powerful 
machines,  a  general  lack  of  understanding  of  software  maintenance  and  structured  pro¬ 
gramming  techniques  created  software  updating  and  portability  problems.  Since  computing 
speed  was  a  dominant  factor  in  programming,  the  programmers  avoided  calls  to  subroutines 
as  a  matter  of  policy.  Programs  were  primarily  one  large  main  segment. 

Fifteen  years  ago,  Winchester  drive  technology  made  possible  disc  drives  with  access 
times  short  enough  to  replace  magnetic  drums.  This  opened  up  practical  use  of  program 
overlays  and  expanded  the  range  of  software  applications  that  could  be  contained  within 
one  program.  While  memory  address  space  was  limited,  codes  which  were  an  order  of  mag¬ 
nitude  more  complex  than  what  was  possible  before  overlays  could  be  implemented  on  the 
computer. 
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Ten  years  ago,  interactive  computing  on  the  mainframe  made  possible  an  explosion  of 
software  development  and  interactive  analyses.  Then  on  the  opposite  end  of  the  computing 
power,  minicomputers  arrived  on  the  market  and  provided  engineering  with  interactive  and 
batch  computing  at  a  cost  many  times  less  than  the  mainframes.  A  few  years  later,  the 
advent  of  the  superminicomputers  opened  up  a  floodgate  of  interactive  applications. 

The  question  of  coding  the  algorithm  gave  way  to  the  reality  that  the  code  had  to  be 
maintained.  Structured  programming  entered,  and  more  readable  code  replaced  subroutine 
calls  overhead.  Software  maintenance  costs  generated  numbers  many  times  the  original 
software  development.  The  question  of  how  to  program  the  task  was  replaced  by  the  ques¬ 
tion  of  how  to  maintain  the  program  and  retain  configuration  control. 

Today,  software  has  taken  over  the  cost  side  of  the  computing  equation  in  some  appli¬ 
cations.  More  frequently,  computing  machines  are  selected  because  they  support  specific 
software  programs.  This  shift  from  the  data  processing  mentality  to  productivity  aware¬ 
ness  is  directly  attributable  to  specialized  software  such  as  circuit  board  design  pack¬ 
ages  and  engineering  workstations. 

The  effective  use  of  some  software  may  require  substantial  training  and  certain  skill 
levels.  This  is  also  a  cost.  In  areas  with  high  employee  turnover,  software  which  is 
user-oriented  and  offers  an  "expert  system"  approach  could  be  a  more  cost-effective  solu¬ 
tion.  The  higher  software  one-time  entry  cost  would  offset  the  reoccurring  higher  train¬ 
ing  costs.  Software  today  can  store  and  disseminate  the  organization's  expertise  in  a 
more  usable  form  than  the  traditional  technical  memos  of  a  few  years  ago. 

COMPUTING  TRENDS 

The  three  primary  functions  in  computing  are:  1)  database  management,  2)  processing, 
and  3)  user  communication.  Five  to  ten  years  ago,  these  three  functions  were  commonly 
found  on  one  computer. 

Structural  design  problems  require  access  to  large  databases.  The  proper  management 
and  direct  access  of  these  databases  are  essential  to  cost-effective  computing  over  the 
long  term.  Sufficient  processing  power  for  both  interactive  and  batch  function  is  also 
critical  to  cost-effective  solutions;  however,  if  engineering  uses  interactive  terminals 
on  the  mainframe  for  its  interactive  functions,  computing  power  for  cpu  or  I/O  intensive 
batch  jobs  will  be  limited.  Therefore,  large  computing  problems  can  be  processed  only 
at  nonprime  times.  This  is  satisfactory  if  there  is  sufficient  capacity  during  nonprime 
times,  and  a  12-hour  turn-around  will  satisfy  schedule  requirements. 

Interactive  computing  has  a  built-in  growth  factor.  The  more  the  user  had  access  to 
interactive  terminals,  the  more  the  user  saw  new  applications.  Soon,  the  mainframes 
became  saturated  with  interactive  functions  during  the  prime  time.  Interactive  response 
times  increased,  and  batch  processing  through-put  reduced  to  a  trickle.  A  mainframe 
which  was  capable  of  performing  large  data  transactions  and  significant  numerical  pro¬ 
cessing  was  not  cost  effective  servicing  interrupts  from  interactive  terminals. 

The  solution  to  this  problem  appeared  under  two  names: 

1)  distributive  computing 

2)  front-end  computers 

If  the  user  completes  the  task  on  the  interactive  computer,  the  facility  is  distributive 
computing.  If  the  user  prepares  a  job  for  the  mainframe,  the  facility  looks  like  a  front- 
end  computer.  The  more  familiar  of  the  front-end/distributive  computers  are  the  VAX 
11/1780  and  the  IBM  4300. 

Applications  for  the  new-found  computer  access  grew  again  as  availability  and  user 
friendliness  increased.  Graphics  applications  in  the  form  of  postprocessors  and  highly 
interactive  preprocessors  were  possible;  however,  as  the  applications  grew,  the  inter¬ 
active  response  times  deteriorated.  Consequently  these  applications  were  not  fully 
implemented  on  the  super  minicomputers. 

As  direct  access  to  the  mainframes  is  removed,  the  mechanics  of  getting  a  job  to  run 
on  the  mainframe  becomes  more  and  more  important.  In  many  computer  installations,  job 
preprocessors  on  the  front-end  computer  prepare  a  job  stream  for  the  mainframe.  The  job 
stream  includes  job  control  language  (JCL) ,  input  data  generators,  and  control  data  for 
data  management.  Even  with  good  job  preprocessors,  however,  the  number  of  jobs  to  be 
submitted  to  the  mainframe  soon  becomes  the  bottleneck  in  the  design  process. 

Computer  networks  are  a  significant  factor  in  superminis  and  workstations  computing 
environments.  The  superminis  manufacturers  such  as  DEC  provide  their  own  network,  VAXNET. 
Some  workstation  manufacturers  such  as  APOLLO  provide  their  own  network,  DOMAIN.  Networks 
based  on  general  LANs  (local  area  network)  are  coming  on-line.  However,  the  hook-up  price 
of  $2000  per  microprocessor  is  still  high  when  compared  to  the  microprocessor  cost  of 
$3500.  If  the  market  were  to  produce  a  full  32-bit  processor  with  floating  point 
co-processor  and  4  Megabytes  of  memory  for  under  $15,000,  then  LANs  would  be  cost  effec¬ 
tive.  Each  microcomputer  could  be  used  effectively  during  off  hours  by  a  master  con¬ 
troller.  Until  now  microprocessors  have  had  limited  applications  in  significant  engineer¬ 
ing  problems. 
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DISCUSSION 

Computer  technology,  computer  marketing,  and  management  appear  to  be  the  primary 
forces  that  will  determine  the  direction  of  the  engineering  computing  environment  during 
the  next  ten  years.  Software  will  act  primarily  as  a  constraint  on  hardware  integrators 
and  manufacturers.  Since  the  cost  of  replacing  or  recoding  existing  software  can  exceed 
many  times  the  cost  of  a  new  machine,  new  hardware  offerings  will  be  compatible  at  the 
computer  operating  system  level  with  an  existing  machine. 

Software  developments  during  the  next  ten  years  will  focus  on  improving  the  perfor¬ 
mance  of  current  software  by  integrating  into  the  engineering  design  methodology  advance 
tools  such  as  “expert"  systems,  advanced  database  management  systems,  and  fifth-generation 
screen  generators,  where  increases  in  productivity  will  offset  the  increase  use  of  com¬ 
puter  resources. 

In  standard  structural  and  dynamic  analyses,  FORTRAN  will  remain  the  primary  pro¬ 
gramming  language.  FORTRAN  77  will  eventually  replace  FORTRAN  IV  and  its  variants,  and 
will  be  upgraded  to  include  some  of  the  UNIX  concepts  such  as  tees  and  unions. 

The  computer  technology  future 

The  con^mter  chip  revolution  will  continue,  and  it  will  affect  the  complete  line  of 
computer  products,  from  microcomputers  to  supercomputers.  The  workstation  computing 
power  will  increase,  and  special-purpose  computer  applications,  such  as  spectral  analyzers 
and  sensor  data  processors,  will  explode. 

The  computing  power  of  mainframes  and  superminis  will  increase,  along  with 
performance-to-price  ratios  for  these  machines.  Hardware  footprints  will  decrease.  If 
the  cost  reductions  of  CMOS  technology  continue  at  their  current  rate,  the  superminis, 
if  not  the  mainframes,  will  operate  without  significant  cooling  requirements. 

Engineering  workstations  with  increased  computer  power  will  process  tasks  that  are 
currently  running  on  superminis.  These  tasks  will  be  interactive  and  graphic-display 
intensive. 

The  current  superminis  will  be  replaced  by  super  microcomputer  systems,  probably 
running  under  some  variant  of  UNIX.  These  will  drive  the  engineering  terminals  for  basic 
data  entry  and  will  probably  front-end  the  mainframe  minis  and  mainframes. 

The  power  of  the  mainframes  will  increase  to  the  point  where  interactive  terminal 
applications  may  again  be  feasible.  For  this  to  be  possible,  the  multiuser  systems 
designed  for  interactive  processing  will  be  running  under  the  native  operating  system, 
such  as  UNIX  under  IBM's  VM  system. 

Computer  marketing  future 

Business  applications  will  continue  to  dominate  the  computer  hardware  and  software 
market  share.  The  market  segment  for  Crays  and  other  supercomputers  will  remain  essen¬ 
tially  constant.  Supercomputers  require  a  constant  flow  of  floating  point  intensive, 
vectorized  codes  in  jobs  where  disk  I/O  is  a  minimum.  While  some  engineering  computing 
jobs  fulfill  this  requirement,  most  do  not.  Therefore,  ten  years  from  now,  the  engineer¬ 
ing  environment  will  not  change  basically  for  problems  requiring  large  databases  and 
significant  amounts  of  floating  point  calculations.  The  bulk  of  engineering  design 
problems  will  remain  on  business  machines. 

While  future  high-tech  design  requirements  may  be  the  motivation  for  increasing  the 
level  of  computer  capacity,  the  computer  technology,  marketing,  and  management  forces 
will  establish  the  level  of  engineering  high-tech  which  a  design  can  economically  support. 
High-tech  engineering  requires  a  high-tech  computing  environment.  Engineering  design 
problems  are  not  solved  cost  effectively  in  earth  orbit  or  after  200  high-tech  vehicles 
come  off  the  assembly  line. 

Management 

Management  sees  three  principal  issues  for  computer  allocations:  cost,  cost,  and 
cost.  The  unstable  element  in  the  word  cost  is  that  it  implies  true  cost,  while  in  fact, 
it  means  perceived  cost.  This  perception  is  a  function  of  accounting  procedures,  manage¬ 
ment  experience,  and  relationship  to  the  organization  goals.  A  growth  organization  per¬ 
ceives  cost  relative  to  maintaining  a  specific  rate  of  growth,  while  for  an  organization 
being  liquidated,  management  perceives  cost  relative  to  maintaining  maximum  short-term 
profits. 

This  perception  issue  often  dominates  talks  with  customers  on  computer  charging. 

A  customer  should  focus  on  the  organization  productivity  factor  relative  to  the  cost 
issue  and  not  on  one  element  of  identifiable  cost.  Cost  reductions  should  be  real.  The 
only  cost  is  that  of  doing  business.  A  close  look  at  the  computer-charging  issue  may 
find  that  the  expense  of  tracking  computer  costs  may  exceed  the  paper  savings  the  cus¬ 
tomer  extracts  from  the  contractor.  In  the  end,  the  customer  pays,  or  the  organization 
fails. 

The  interaction  between  cost,  organization  goals,  and  management  is  the  critical 
issue  in  establishing  the  productivity  criteria  for  computer  resource  allocations.  While 
each  organization  has  its  own  process  for  the  interaction,  a  number  of  common  issues  are 
obvious : 
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1)  Management  wants  flexibility /elasticity  in  computer  facility  architecture.  The 
optimum  is  instant  expansion  or  instant  contraction  around  a  core  of  committed 
resources.  The  expansion  or  contraction  should  be  transparent  to  the  user 
community. 

2)  The  expansion  or  contraction  of  the  computer  resources  should  be  the  basis  of 
reducing  project  costs,  meeting  committed  schedules,  and  satisfying  design  goals. 
The  computer  expansion  requirements  should  be  known  at  the  time  management 
commits  to  a  project  for  a  specific  cost  and  schedule.  Contraction  of  computer 
resources  should  be  on  an  over-capacity  or  unused- resources  basis,  unless  the 
organization  intends  not  to  support  a  specific  technology  base. 

3)  The  expense  of  new  hardware  and  updating  existing  hardware  must  reflect  the  cost 
of  business  and  not  an  abstract  increase  in  computer  facility  budget. 

A  blueprint  for  the  future 

The  blueprint  should  accommodate  the  future  and  still  direct  the  overall  effort  to 
improve  the  engineering  computing  environment,  with  special  emphasis  on  software  use. 

The  challenge  is  to  suggest  a  clear  alternative  which  will  be  cost-effective  and  remain 
compatible  with  the  established  and  known  forces  of  computer  marketing  and  management 
resource  allocation  practices. 

The  goal  of  the  proposed  blueprint,  then,  is  to  provide  an  approach  which  will: 

1.  lower  engineering  computing  costs. 

2.  adjust  to  the  cyclic  nature  of  engineering  computing  resource  requirements. 

3.  be  compatible  with  the  primary  computing  marketing  force,  business  applications. 

4.  address  the  I/O-bound  computing  tasks  as  well  as  the  floating  point  cpu-bound 
computing  tasks  with  and  without  vectorized  code. 

5.  give  management  greater  cost  control  and  flexibility  while  integrating  new 
computer  technology. 

6.  permit  enlightened  management  to  take  advantage  of  the  computer  as  a  productive 
tool. 

7.  lower  the  risk  of  vendors  trying  to  service  engineering  requirements. 

8.  promote  software  development  which  is  modular,  transportable,  low-maintenance, 
and  computer  installation  sized  independent. 

9.  be  compatible  with  existing  software. 

10.  permit  management  to  appraise  software  as  a  company  asset. 

11.  increase  the  interactive  computing  capability. 

12.  integrate  advanced  developments  in  hardware  and  software  technology,  such  as 
parallel  processing. 

AN  APPROACH 

The  blueprint  for  improving  the  engineering  computing  'environment  during  the  next 
ten  years  must  satisfy  management  and  user  goals  and  recognize  simultaneously  the  reali¬ 
ties  of  the  computer  marketplace  (business)  and  computer  technology  advancements  (con¬ 
trolled  chaos).  The  issues  for  management  are  cost,  flexibility,  and  control.  The 
issues  for  engineering  are  good  computer  interfaces,  adequate  software  tools,  and  access 
to  the  hardware  resources  required  to  satisfy  project  goals,  and  schedules. 

The  ideal  batch  processing  hardware  should  have  the  data  record  transaction  effi¬ 
ciency  and  the  operating  system  flexibility  of  an  IBM  30XX,  the  floating-point  scalar 
processing  efficiency  of  a  CDC  7600,  the  vectorized  floating-point  efficiency  of  a  Cray, 
and  the  modularity  of  peripheral  additions.  Business  and  manufacturing  are  the  primary 
customers  of  a  typical  computer  installation.  Therefore,  the  core  computer  function 
must  be  a  highly  efficient  data-transaction  machine. 

The  goals  listed  above  do  not  necessarily  imply  that  they  are  either  sufficient  or 
necessary  conditions  for  a  satisfactory  computing  environment.  They  are  the  starting 
point  to  the  definition  of  a  working  blueprint. 

Lacking  an  ideal  batch  processor,  the  issue  is  whether  a  basic  business  computer  can 
form  the  core  of  a  good  engineering  computing  system  which  will  address  the  resource 
requirements  of  the  structural  design  during  high  and  low  levels  of  design  activity.  The 
proposed  computing  system  uses  the  high-transaction  (host)  mainframe  computer  as  the 
primary  organizer  of  work  to  be  done,  of  data  to  be  managed,  of  output  to  be  sent,  of 
resources  to  be  allocated,  and  of  computing  requests  to  be  serviced. 

In  this  configuration,  the  host  mainframe  is  encircled  by  independent  floating-point 
processing  computers  which  have  their  own  memory  and  disc  units.  The  host  mainframe 
while  executing  a  job  would  identify  a  cpu-intensive,  floating-point  processing  task, 
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package  the  cpu-intensive  task,  and  send  it  to  an  auxiliary  computer  to  be  processed. 

The  auxiliary  computer  could  be  a  CDC  machine,  an  array  processor,  a  l-to-5  MIPS  32-bit 
MC68020-based  machine,  or  a  Cray. 

The  key  to  this  architecture  is  the  modularity  of  the  auxiliary  con$>uters  and  the 
ability  of  the  host  mainframe  to  function  independent  of  the  auxiliary  computer.  At  low 
levels  of  activity,  the  auxiliary  computers  could  be  removed.  Maximum  effectiveness  of 
new  low-end  computing  chips  could  be  used  to  provide  more  MIPS  at  lower  cost.  This 
architecture  would  also  enable  the  cost-effective  tuning  of  some  of  the  auxiliary  com¬ 
puters  to  perform  functions  such  as  matrix  inversion  and  matrix  multiply. 

A  blueprint  for  a  computing  environment  to  satisfy  the  objectives  stated  above 
depends  on  two  critical  components: 

1)  the  definition  of  a  floating-point  computing  engine  (FPCE)  interface  with  a 
transaction-based  computer  (host  mainframe) . 

2)  the  definition  of  a  computer  processing  system  which  will  integrate: 

a)  the  floating-point  computing  engines  resources 

b)  the  mainframe  resources 

c)  existing  independent  computing  software  into  a  complete  computing  system 
without  changing  the  existing  software. 

FPCE  interface-  The  concept  of  a  floating-point  computing  engine  is  not  new.  The 
Crays,  Floating  Point  Systems  array  processors,  and  Ridge  computers  are  in  fact  floating¬ 
point  engines.  They  specialize  in  performing  floating-point  calculations  at  the  super¬ 
computer,  attached  processor,  and  microprocessor  levels.  Some  of  these  engines  are 
tightly  coupled  with  the  host  processor,  and  others  are  stand-alone  computers  which  need 
a  front-end  processor  to  prepare  the  job.  The  issue  here  is  the  communication  between 
the  engine  and  the  host  mainframe  computer. 

If  an  interface  were  to  exist,  the  computer  hardware  integrator  could  develop  a  com¬ 
puter  which  would  address  the  floating-point  computing  environment,  whether  on  scalar  or 
vectorized  code.  If  the  standard  FPCE  interface  were  supported  by  the  FPCE  manufacturer, 
its  product  could  be  a  potential  add-on  to  any  high-transaction  machine  that  also  sup¬ 
ported  the  FPCE  interface. 

The  economic  and  flexibility  advantages  of  this  system  are  obvious.  During  slow 
design  activity,  the  computing  organization  would  support  engineering  with  a  minimal  num¬ 
ber  of  these  computing  engines.  As  the  design  activity  increased,  the  computing  organi¬ 
zation  would  attach  more  computing  engines  to  satisfy  engineering  computing  needs.  The 
method  of  processing  the  job  could  be  completely  transparent  to  the  user,  or  the  user 
could  route  the  job  to  go  to  one  or  more  of  the  computing  engines. 

To  be  an  effective  interface,  the  host  computer  must  see  the  interface  as  a  cross 
between  another  device  and  a  remote  job  entry  port.  The  interface  must  have  data  trans¬ 
fer  rates  close  to  disc  devices.  If  the  computing  engine  is  a  single  task  processor, 
the  full  resources  of  the  engine  could  be  available  to  transfer  data  at  the  host  inter¬ 
face  speed.  However,  since  the  elapsed  time  between  sending  the  job  to  the  engine  and 
receiving  the  results  could  be  hours,  some  type  of  communication  protocol  which  defines 
the  status  of  the  computing  engines  and  the  host  computer  would  be  required. 

Figure  2  shows  a  typical  host  mainframe  installation  with  an  FPCE  interface  to  an 
FPCE  computer.  The  figure  also  shows  the  mainframe  with  a  front-end  super  minicomputer 
and  direct  terminal  access  ports. 

The  FPCE  interface  is  not  defined  at  this  time.  It  may  be  based  on  local-area  net¬ 
works  (LANs)  or  it  may  be  based  on  something  altogether  different.  The  functional 
aspects  of  FPCE  are  shown  in  Figure  3,  where  the  interface  commands  to  the  engine  define 
the  source  code,  linked  code  to  be  loaded  directly,  data,  time  estimate,  device  alloca¬ 
tions  and  the  commands  to  inquire  the  host  status,  time  estimate  to  completion,  compiled 
and  linked  codes,  and  results.  Special  consideration  must  be  paid  to  the  problem  if 
either  or  both  the  host  computer  and  auxiliary  computers  should  fail  during  the  process¬ 
ing  of  the  job  submitted  to  the  host. 

Extended  Batch  User  System-  Software  exits  in  primary  two  forms: 

1)  modular  (executable)  software  as  found  in  the  UNIX-like  operating  systems  where 
the  input/output  streams  are  well-defined  and  simple. 

2)  integrated  software  built  around  an  internal  (sometimes  accessible  from  the 
outside)  database  as  found  in  NASTRAN,  where  input/output  streams  are  complex 
and  difficult  to  assemble. 

Figure  4  shows  the  contrast  between  modular  and  integrated  software.  Modular  soft¬ 
ware  stands  by  itself.  As  long  as  the  input  data  is  on  the  designatec  units  and  the  out¬ 
put  data  can  go  to  other  designated  units,  the  modular  software  computes.  Integrated 
software  has  its  own  database.  Data  required  to  run  routine  "B"  in  Figure  4  may  have  to 
go  through  routine  "A"  where  it  is  catalogued  and  put  into  a  standard  form  which  will  be 
recognized  by  *B".  The  MAIN  must  read  additional  control  cards  to  execute  "B"  and  out¬ 
put  the  data  to  the  outside  world. 
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FIGURE  2.  HOST  COMPUTER  WITH  FPCE  INTERFACE 


FI6URE  3.  A  TYPICAL  FPCE  INTERFACE  DEFINITION 


In  the  past,  the  integrated  software  approach  was  necessary  to  achieve  efficient 
control  over  the  execution  of  "A",  "B",  etc.,  routines.  The  integrated  software  provided 
either  a  self-contained  attaching  monitor  system,  as  found  ir.  NASTRAN  under  the  IBM  370 
operating  system,  or  OVERLAYS  which  contain  SUBROUTINES  called  from  the  MAIN  segment. 

The  OVERLAY  approach  is  used  by  many  integrated  software  systems,  including  Boeing's 
ATLAS,  Lockheed's  FAMAS ,  and  Lockheed's  NICE. 

The  drawback  of  these  systems  is  the  very  reason  that  they  are  so  powerful,  namely, 
complexity.  It  is  not  a  trivial  exercise  to  either  add  a  function  to  these  systems  or 
to  modify  an  existing  routine.  One  of  the  NICE  system  features  is  that  it  is  probably 
the  easiest  of  all  the  integrated  software  systems  to  change  or  to  add  routines  to. 

None  of  these  integrated  systems  suggests  the  practicality  of  integrating  one  integrated 
software  system  into  another  integrated  software  system. 

This  was  the  problem  that  was  addressed  in  developing  an  integrated  software  oper¬ 
ating  system  called  Continuous  Batch  User  System  (CBUS)  at  Lockheed-Ca 1 i for r.i j  Company. 
CBUS  attaches  to  any  executable  load  module  and  initiates  execution.  These  modules 
include  NASTRAN,  FAMAS,  and  simple  standalone  programs. 

CBUS  permits  the  modular  coding  of  software  into  executable  load  modules,  which  may 
be  as  small  as  two  FORTRAN  statements.  These  modules  are  coded  and  checked  out  on  front- 
end  computers  where  the  interactive  capabilities  facilitate  coding  and  debugging.  These 
modules  are  then  moved  to  the  mainframe  and  integrated  under  CBUS  with  no  modification 
to  the  source  code.  CBUS  permits  software  development  by  many  programmers  without  undue 


3-13 


concern  about  data  interfaces.  The  macros  in  CBUS  permit  the  definition  of  engineering 
processes  which  represent  particular  developments  of  specialists.  An  alter  capability 
permits  the  user  to  define  keywords  which  will  trigger  almost  an  unlimited  number  of 
changes  to  the  macro  with  embedded  defaults.  The  feature  permits  addition  of  functions 
to  the  process  without  changing  the  original  definition. 

CBUS  uses  the  modules  in  the  same  form  as  that  required  by  simple  batch  submittals. 
CBUS  is  an  integrated  operating  system,  which  for  the  first  time  not  only  permits  but 
encourages  a  computing  function  to  be  in  modular  format  by  its  loosely  coupled  architec¬ 
ture.  In  its  simple  form,  CBUS  executes  "A",  “B",  etc.,  as  shown  in  Figure  5,  in  a  con¬ 
tinuous  sequence.  The  modules  "A",  etc.,  represent  any  modules  accessible  to  the  computer 

CBUS  is,  however,  more  than  an  attaching  monitor.  It  is  a  resource  allocator  and  a 
user  command  processor;  it  executes  user  commands  which  represent  a  process  or  task. 

A  simple  one-line  command  may  represent  a  complex  process  which  requires  the  execution  of 
a  hundred  equivalent  batch  programs.  Each  process  is  completely  defined  by  the  user  in 
a  MACRO  structure.  One  set  of  commands  under  this  operating  system  will  execute  the 
equivalent  of  300  to  500  batch  programs. 


FIGURE  5  LOOSELY  COUPLED  PROCESSES  UNDER  CBUS 
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Figure  6  shows  the  basic  elements  of  CBUS.  Target  programs  are  any  executable  load 
modules,  which  also  include  compilers  and  linkers.  Within  the  command  processor  program 
(CPP) ,  the  alter  capability  is  the  key  to  the  operational  flexibility  of  CBUS.  Alter 
capability  permits  the  user  to  name  a  keyword  which  enables  the  MACRO  to  be  altered 
during  the  execution  of  the  engineering  process.  Some  features  of  the  command  language 
are  found  in  Figure  7  where  simple  commands  are  integrated  into  another  MACRO  called 
super-command.  Figure  8  shows  some  of  the  elements  of  the  alter  capability. 

The  major  benefit  of  this  architecture  is  the  control  that  user  exercises  over  the 
problem  being  solved.  The  user  not  only  defines  processes  which  use  complex  integrated 
software  such  as  NASTRAN,  but  with  minimum  effort,  the  user  can  insert  a  completely  new 
process  without  interfering  with  anyone's  use  of  the  same  macros.  While  CBUS  is  a  struc¬ 
ture  to  build  integrated  systems  from  a  user  point  of  view,  it  is  not  new;  but  has  been 
used  for  the  past  seven  years  and  has  survived  many  operating  system  changes.  Refer¬ 
ences  1  and  2  discuss  some  of  the  CBUS  details  as  well  as  its  application  to  preliminary 
aeroelastic  design  of  structures  (PADS) . 


FIGURE  7  CBUS  COMMRNOIRRCRO  STRUCTURE 
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FIGURE  8.  CBUS  ALTER  CAPABILITY 


CBUS  architecture  needs  to  be  extended  for  interaction  with  the  FPCE  interface.  New 
features  in  the  CBUS  monitor,  resource  allocator,  and  command  processor  should  include: 

1)  putting  the  computing  task  asleep  when  the  mainframe  must  wait  for  the  task  on  the 
floating  point  engine  to  be  completed,  2)  computing  task  wake  up  call  when  the  engine 
task  is  completed,  3)  Tees  and  unions  to  permit  parallel  processing  on  both  the  engines 
and  mainframe.  While  CBUS  is  currently  running  only  on  the  IBM  370  operating  system, 
the  software  could  be  migrated  to  other  mainframes.  The  concept  is  to  buiM  one  inte¬ 
grating  software  operating  system  which  will  permit  simple  control  and  execution  of  modu¬ 
lar  software  rather  than  to  integrate  the  whole  process  into  an  existing  integrated 
software  such  as  NASTRAN.  CBUS  is  an  example  of  a  software  integrator  which  operates 
external  to  all  programs  running  under  its  control. 

The  extended  CBUS  concept  could  be  called  XBUS. 

CONCLUSIONS 

The  computer  technology  developments  are,  and  will  remain  for  the  forseeable  future, 
in  a  state  of  controlled  chaos.  Engineering  cannot  remain  a  passive  observer  of  this 
process  and  expect  the  computer  developments  to  automatically  and  cost-effectively  address 
the  needs  of  the  engineering  design  process.  Engineering  must  review  its  requirements 
and  define  a  market  segment  which  computer  system  integrators  will  recognize  as  an  area 
with  acceptable  risks. 

In  software,  engineering  must  recognize  the  need  for  more  modular  software  architec¬ 
ture,  which  is  not  possible  in  a  large  integrated  computing  program.  Engineering  needs 
change  and  the  software  integration  procedures  must  accept,  as  the  basic  premise,  flexi¬ 
bility  and  change. 

Engineering  must  control  its  computing  environment  in  the  face  of  serious  economic 
pressures  created  by  a  rapidly  changing  computing  industry  which  views  the  engineering 
computing  needs  as  a  small  footnote  in  the  computing  marketing  picture. 

The  following  are  observations  and  conclusions  in  support  of  the  above  statements: 

1)  The  digital  computer  market  is  dominated  by  business  applications. 

2)  Business  machines  are  cost-efficient,  data-transaction  processors  and  database 
machines. 

3)  Business  machines  are  no^.  cost-efficient,  cpu-intensive  processors. 

4)  Future  computer  technolc  gy  developments  will  continue  the  current  trend  of 
increasing  performance-to-cost  ratios. 

5)  Superminis  processing  power  will  increase  to  current  mainframe  levels  within 
10  years. 


6)  Microcomputers  processing  power  will  increase  to  current  superminis  levels 
within  2  years. 
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7)  Structural  design  process  requires  the  data-transaction  power  of  a  business 
machine,  the  scalar  processing  power  of  a  CDC  machine,  and  the  vector  processing 
power  of  a  Cray. 

8)  Management  perception  of  computing  costs  is  a  major  factor  in  establishing  the 
engineering  computing  environment. 

9)  Management  desires  computing  capacity  elasticity  and  computing  cost  effective¬ 
ness  from  a  computer  facility. 

10)  Software  costs  are  in  some  applications  the  major  element  in  the  computing  cost 
equation. 

11)  Current  integrated  software  packages  are  difficult  to  maintain  and  modify,  and 
are  not  portable. 

12)  A  software  integrator,  called  CBUS,  permits  the  integration  of  diverse  computer 
programs  and  integrated  software  systems  such  as  NASTRAN  without  altering  the 
code  of  the  programs  being  integrated. 

13)  Cost-effective,  floating-point  computing  engines  (FPCE)  which  are  based  on 
complete  32-bit  microprocessors  are  technically  feasible. 

14)  An  FPCE  interface  definition  is  required  to  stimulate  the  computer  system 
integrators  to  supply  engineering  with  the  modular  computing  cells.  The  inter¬ 
face  is  between  the  host  computer  and  the  FPCE  computers. 

15)  An  extension  of  the  CBUS  system  will  permit  the  integration  of  the  floating-point 
computing  engine  as  another  computing  resource  as  well  as  disk,  tape  drives,  and 
memory . 

16)  A  computer  facility  based  on  a  host  computer  (transaction  processor)  and  FPCE 
computers  would  reduce  the  cost  of  a  cpu  intensive  task  by  an  order  of  magnitude. 
The  host  computer  performance  would  not  be  seriously  degraded  while  servicing 
engineering  cpu-intensive  tasks.  The  engineering  jobs  would  continue  to  benefit 
from  the  cost-effective  data  management  and  transaction  capabilities  of  the  host 
computer.  Increasing  or  decreasing  cpu-intensive  computing  requirements  from 
engineering  could  be  satisfied  by  the  addition  or  removal  of  FPCE  computer  units 
without  affecting  the  operation  of  the  host  computer. 

17)  The  CBUS  concept  permits  the  development  of  software  in  loosely  coupled  modular 
units  which  can  be  integrated  into  a  single  named  process.  The  integration  is 
at  the  user  level  and  is  controlled  by  the  user.  Inserting  a  new  element  into 
the  process  or  changing  an  element  of  the  process  is  trivial. 

RECOMMENDAT IONS 

1)  Form  an  engineering  user  group  to  establish  requirements  for  hardware  develop¬ 
ment  which  will  make  engineering  computing  more  cost-effective. 

2)  Investigate  the  potential  or  forming  an  interface  protocol  between  the  host 
computer  and  auxiliary  computers. 

3)  Investigate  the  potential  of  a  software  integrator  system  architecture  which 
was  used  in  CBUS. 


REFERENCES 

1  Radovcich,  N.  A.,  "Preliminary  Aeroelastic  Design  of  Structures  (PADS)  Methods 
Development  and  Application,"  Presented  at  the  56th  meeting  of  the  AGARD  STRUCTURES 
and  MATERIALS  PANEL  Specialists  meeting;  London,  United  Kingdom  10-15  April,  1983. 

2  Radovcich,  N.  A.,  "Some  Experience  in  Aircraft  Aerolastic  Design  Using  Preliminary 
Aeroelastic  Design  of  Structures  (PADS),"  NASA  Symposium  on  recent  experience  in  multi¬ 
disciplinary  analysis  and  optimization,  Hampton,  VA. ,  April  24-26,  1984. 


THE  NEEDS  OF  THE  USAF  AIR  LOGISTICS  CENTERS 
FOR  LARGE  SCALE  STRUCTURAL  ANALYSES  AND 
SUPPORTING  DATA 


by 

Dr.  Thomas  F.  Christian,  Jr. 

System  Program  Management  Division 
Warner  Robins  Air  Logistics  Center 
WR-ALC/MMSRD,  Robins  AFB  GA  31098-5609  USA 


SUMMARY 

This  pilot  paper  reviews  the  structural  analysis  capabilities  both  now  existing  and 
projected  as  needed  within  five  years  at  the  USAF  Air  Logistics  Center  In  order  to  support 
USAF  operational  aircraft.  The  various  structural  analysis  and  supporting  data  areas 
addressed  In  this  paper  as  part  of  airframe  force  management  Include  life  prediction 
techniques,  finite  element  modeling,  electronic  data  bases,  risk  assessment  and  newly 
Introduced  advanced  structural  materials. 

INTRODUCTION 

"I  always  avoid  prophesying  beforehand,  because  it  Is  a  much  better  policy  to  prophesy 
after  the  event  has  already  taken  place"  -  Winston  Churchill. 

At  the  risk  of  disregarding  thl8  sage  advice  of  Mr  Churchill,  prophesy  concerning  the 
structural  analysis  requirements  at  the  U.S.  Air  Force's  Air  Logistics  Centers  (ALCs) 
during  the  next  five  years  does  need  to  be  made  now.  A  path  that  can  not  be  seen,  even 
dimly.  Is  a  path  that  may  lead  to  a  tumble.  As  the  repair  depots  and  industrial 
facilities  of  the  Air  Force,  the  five  ALCs  are  now  ready  to  dramatically  enhance  their 
technological  expertise  In  the  structural  analysis  arena.  This  paper  will  focus  on  the 
various  areas  In  which  efforts  are  now  being  made  such  as  life  prediction,  finite  element 
modeling,  risk  assessment,  flight  history  recording  and  Introduction  of  new  materials  Into 
greater  operational  use. 

It  must  be  remembered  that  until  recently  the  structural  analysis  requirements  at  an  ALC 
were  quite  uncomplicated.  This  was  due  to  several  factors.  First  and  foremost,  the  Air 
Force  Systems  Command  (AFSC)  conducted  new  aircraft  acquisition  through  the  Aeronautical 
Systems  Division  (ASD)  at  Wrl gh t-Pa t te rs on  AFB  OH  with  research  and  development  support 
from  the  nearby  Flight  Dynamics  and  Materials  Laboratories.  With  the  preponderance  of 
structural  engineers.  It  was  and  Is  the  charter  of  AFSC  to  ensure  an  adequate  airframe  is 
delivered  to  the  Air  Force.  Working  in  conjunction  with  the  airframe  manufacturer's 
research  and  development  engineers  and  design  and  manufacturing  staffs,  AFSC  has  performed 
this  function  well.  Once  an  aircraft  enters  operational  service.  It  becomes  the 
responsibility  of  the  Air  Logistics  Centers  of  the  Air  Force  Logistics  Command  (AFLC) 
until  Its  retirement.  As  a  result  of  this  approach,  for  many  years  structural  analysis  at 
the  ALC's  consisted  of  referring  to  the  stress  analysis  reports  furnished  by  the  airframe 
manufacturer  and  ensuring  that  any  proposed  repair  would  restore  sufficient  strength. 
Relatively  simple  calculations  of  P/A  and  Mc/I  were  often  all  that  were  necessary  to 
satisfy  the  ALC  mission  of  supporting  In-service  aircraft  and  keeping  them  airworthy.  As 
aircraft  have  remained  In  operation  longer  than  originally  foreseen  when  they  were 
designed,  structural  fatigue  and  corrosion  have  assumed  greater  prominence  and  required 
greater  engineering  attention  at  the  ALCs.  Added  to  this  is  the  mul 1 tl pi 1  cl ty  of 
unanticipated  missions  which  have  been  acquired  by  virtually  every  series  of  military 
aircraft  and  which  have  caused  the  need  for  more  engineering  resources. 

Diversity  and  age  of  airframe  configurations  within  an  aircraft  force,  such  as  the  C-130 
transport  which  has  been  In  production  since  1955,  also  plays  a  role  In  requiring  the 
enhancement  of  structural  analysis  capabilities  at  the  ALCs.  The  current  efforts  and 
future  needs  in  each  of  the  structural  analysis  disciplines  at  the  ALCs  will  now  be 
delineated. 

LIFE  PREDICTION  FOR  FATIGUE  AND  FRACTURE 

"To  repair  the  Irreparable  ravages  of  time"  -  Jean  Racine. 

For  the  foreseeable  future,  fatigue  life  prediction  will  occupy  the  predominant  position 
among  the  structural  analysis  needs  at  the  Air  Logistics  Centers.  Each  Air  Logistics 
Center  has  several  System  Program  Managers  (SPM)  to  support  the  aircraft  forces  assigned 
to  It,  for  instance,  the  Warner  Robins  Air  Logistics  Center  (WR-ALC)  is  responsible  for 
the  C-130,  C-141,  F  —  1 5  and  all  Air  Force  helicopters.  A  principal  SPM  activity  for 

ensuring  the  structural  health  of  operational  aircraft  Is  known  as  the  Aircraft  Structural 

Integrity  Program  (ASIP)  as  codified  in  AFR  80-13. 1  The  requisite  functional  tasks  to 
ensure  adequte  airframe  quality  are  delineated  in  MIL-STD-1 530A^  as  design  criteria, 
design  analysis  and  develoment  tests,  full  scale  testing,  force  management  data  package 
and  force  management.  The  airframe  manufacturer  and  ASD  are  responsible  for  the  first 
four  Items  and  the  last  one  Is  the  purview  of  the  ALC.  These  five  tasks  substantiate  the 

structural  Integrity  of  the  aircraft  design,  assess  the  In-service  Integrity  of  Individual 

airplanes,  determine  logistics  requirements  and  Improve  future  design  methods.  Central  to 
all  of  activities  are  the  concepts  of  durability  and  damage  tolerance  assessment  (DADTA) 
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established  with  the  Issuance  of  MIL-STD-1 530A  and  Its  associated  military  specifications, 
MIL-A-834443,  MIL-A-8866B4  and  MIL-A-886 78B 5. 

Damage  tolerance  is  defined  by  the  U.S,  Air  Force  as  the  ability  of  an  airframe  o  resist 
failure  due  to  the  presence  of  flaws,  cracks,  or  other  damage  for  a  specified  period  of 
unrepaired  usage.  Damage  tolerance  analysis  (DTA)  thus  becomes  an  Investigation  of  crack 
growth  and  the  residual  strength  possessed  by  the  damaged  structure.  It  focuses  on 
primary  or  "safety  of  flight"  structure  which  Is  assumed  to  contain  Initial  undetected 
flaws  which  could  likely  be  missed  during  an  Inspection.  The  safety  limit  at  a  given 
location  on  an  airframe  Is  then  the  number  of  flight  hours  required  for  a  crack  to  grow 
from  the  assumed  flaw  size  to  a  critical,  or  a  catastrophic  failure,  crack  length. 
Durability,  on  the  other  hand,  Is  not  a  "safety  of  flight"  concept  but  rather  an 
economical  one  which  measures  the  ability  of  the  airframe  to  resist  cracking,  corrosion, 
wear,  etc.  for  a  specified  period  of  time.  Durability  limits  are  associated  with  the  cost 
of  in-service  repair  such  that  initial  flaws,  which  are  not  safety  of  flight,  will  not 
grow  large  enough  to  require  extensive  repair  before  one  service  lifetime. 

Under  present  procedures,  the  airframe  manufacturer  conducts  an  initial  baseline  or  total 
airframe  DADTA  under  Air  Force  contract  (see,  for  example,  References  6  and  7).  This  may 
require  IS  to  20  contractor  and  Air  Force  engineers  from  one  to  three  years  depending  on 
the  specific  airframe  complexity^.  The  number  of  critical  locations  varies  but  generally 
speaking  larger  aircraft  have  more  than  smaller  aircraft,  perhaps  over  100  for  a  bomber/ 
transport  class  and  less  than  100  for  a  f 1 gh t e r /a t t ach  type.  Regardless  of  the  number  of 
locations  considered  In  the  baseline  study,  It  Is  obvious  that  other,  unanticipated 
locations  will  surface  during  operational  service.  The  mullplicity  of  mission  changes 
subsequent  to  a  baseline  study  as  well  as  the  prohibitive  cost  of  an  Inclusive  study  make 
such  occurrences  Inevitable.  For  this  reason,  the  ALCs  must  have  the  capability  to 
analyze  such  locations  organically. 

Conducting  a  f 1 1 gh t -by-f 1 1 gh t  crack  growth  analysis  organically  at  an  ALC  requires  of 
course  the  same  procedures  as  undertaken  by  the  airframe  manufacturer  In  the  baseline 
study.  It  requires  Incorporation  of  the  following  elements: 

(a)  the  Initial  flaw's  size  and  shape 

(b)  the  aircraft  usage  stress  spectra 

(c)  data  for  material  fracture  toughness  and  constant  amplitude  crack  growth  rate 

(d)  crack  tip  stress  Intensity  factors 

(e)  damage  integration  and  load  Interaction  models 

(f)  the  fracture  criterion 

These  elements^  are  shown  schematically  In  Figure  1.  Naturally,  the  result  of  this 
analysis  is  the  crack  growth  curve,  as  Illustrated  in  Figure  2,  from  which  the  length  of 
the  crack  at  any  time  before  the  safety  limit  can  be  obtained.  This  then  provides  the 
information  necessary  to  select  non-destructive  Inspection  (NDI)  techniques  and  to  set 
Inspection  Intervals  or  to  plan  structural  modifications. 

The  Air  Force  experience  with  DTA  during  the  decade  since  its  Introduction10  has  been 
good.  The  ALCs  are  the  beneficiaries  of  the  outstanding  efforts  of  the  airframe 
manufacturers  and  the  AFSC  organizations  which  have  pioneered  this  methodology  as  a 
replacement  to  the  previous  linear  accumulation  fatigue  damage  approach.  As  this 
methodology  has  been  made  available  to  the  ALCs,  concomitant  decisions  have  been  necessary 
as  to  the  level  of  organic  DTA  desired  at  a  given  ALC.  The  choice  then  determines  the 
requirements  for  large  scale  structural  analysis.  Five  possible  levels11  have  been 
Identified  as  follows: 

Level  I:  Review  In-House.  This  Is  the  most  primitive  level  of  organic  DTA  effort. 

It  requires  no  structural  analysis  software  or  hardware  capability  since  ALC  engineers 
merely  review  work  performed  by  contractors. 

Level  II:  Structural  Analysis  of  Repairs.  This  level  Introduces  finite  element 
analysis  techniques  on  a  minicomputer  or  time  sharing  on  a  larger  mainframe.  Graphics 
terminals  employing  a  pre  and  post  processor  to  generate  structural  models  and  display 
output  results  such  as  deformations  and  stresses  are  highly  desirable. 

Level  III:  DTA  on  Structural  Components.  Building  on  the  hardware  resources  of  Level 
II,  this  level  adds  f 1 lgh t-by-f 1 Igh t  fatigue  crack  growth  calculation  capability  using 
software  such  as  the  USAF  Flight  Dynamics  Laboratory  ( AFFDL )  developed  CRACKS  series1^. 
With  the  modification  or  development  of  stress  spectra  and  mission  mixes,  predictions  of 
safety  limits  and  establishments  of  Inspection  intervals  becomes  possible. 

Level  IV:  Abbreviated  Airframe  DTA.  This  level  requires  specific  f 1 1 gh t-by-f 1 1 ght 
crack  growth  software  for  each  aircraft  type  being  analyzed.  Preferably,  this  software 
will  be  developed  by  the  airframe  manufacturer  as  part  of  the  initial  DTA  on  that 
aircraft.  A  technical  specialist  for  each  aircraft  type  Is  highly  sdvlsable. 


Level  V:  Complete  Airframe  DTA.  This  final  level  of  organic  DTA  capability  utilizes 
the  finite  element  and  f 1 1 gh t -by-f 1 1 gh t  crack  growth  software  of  the  previous  levels  for  a 
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comprehensive  DTA  effort.  It  la  essential  for  such  an  effort  that  both  a  umber  of  highly 
experienced  engineers  and  computer  scientists  as  well  as  a  dedicated  computer  facility 
with  at  least  a  super  minicomputer  be  available. 

At  the  present  time  the  five  ALCs  vary  considerably  In  their  organic  DTA  capabilities  but 
It  does  not  appear  farfetched  to  predict  that  within  the  next  five  years  all  the  ALCs 
could  be  at  the  IV/V  plateau  which  WR-ALC  has  achieved.  This  cannot  be  accomplished, 
however,  without  the  close  cooperation  of  each  ALC  with  the  various  airframe  manufacturers 
of  Its  assigned  aircraft  and  the  cognizant  AFSC  organizations  such  as  ASD  and  AFFDL.  A 
strong  partnership  between  these  groups  recognizes  that  an  ALC's  organic  DTA  capability 
will  help  achieve  the  common  goal  of  airframe  structural  integrity.  The  enhanced 
proficiency  of  ALC  personnel  promotes  a. mutually  beneficial  exchange  of  expertise.  This 
rapport  must  be  fostered  since  DTA  at  an  ALC  cannot  supplement  the  role  of  AFFDL  to 
develop  Improved  life  prediction  methodology.  Nor  can  it  supersede  the  need  for  close, 
continuous  airframe  manufacturers  Involvement  over  the  lifetime  of  the  aircraft  due  to  the 
unique  information  and  analysis  resources  possessed  by  the  manuf acturer.  Using 
manufacturer  developed  aircraft  specific  software  at  the  ALC  to  vary  mission  profiles  and 
mixes,  determine  flight  loads  and  stress  spectra,  and  finally  calculate  crack  growth 
curves  cements  a  good  working  relationship  between  the  engineering  staffs  as  well  as  also 
minimizing  the  possibility  of  divergent  results  for  similar  analyses.  In  this  vein,  the 
experience  of  the  organic  DTA  group  at  WR-ALC  with  its  counterparts  at  the  Lockheed- 
Ceorgla  Company,  the  McDonnell  Aircraft  Company  and  the  Sikorsky  Aircraft  Company  has  been 
very  satisfactory.  Equally  positive  has  been  the  ability  of  WR-ALC  to  apply  DTA 
methodology  to  the  practical  requirements  of  day  to  day  force  management  and  to  maintain  a 
rapid  response  capability  for  operating  commands'  needs. 

Specific  needs  for  organic  DTA  within  the  next  five  years  focus  upon  user-friendly,  menu 
driven  Integration  of  the  elements  shown  in  Figure  1.  An  excellent  first  step  Is  the 
CRKGRO  program  13  deve 1  oped  by  Rockwell  under  AFFDL  contract.  It  has  a  very  good  selection 
of  stress  Intensity  solutions  for  various  crack  shapes  in  flat  plates.  In  practice,  It  Is 
the  determination  of  stress  Intensities  for  the  various  airframe  details  that  is  the  most 
tedious  and  time  consuming  portion  of  the  DTA  analysis.  Present  techniques14  require 
either  compounding  classical  solutions  such  as  back  surface  modification,  finite  width 
effect,  etc.  or  the  construction  of  a  detailed  finite  element  model  to  use  a  crack  tip 
element,  strain  energy  release  rate,  crack  opening  displacement,  etc.  Consequently, 
further  work  Is  needed  to  develop  a  stress  intensity  solution  or  "Beta  factor"  data  base 
that  can  be  used  to  accurately  and  rapidly  establish  geometric  correction  factors  for 
configurations  more  complex  than  a  plate  with  or  without  a  hole. 

Work  i 8  well  underway  to  build  extensive  material  property  data  bases  for  integration  into 
the  crack  growth  analysis  software.  Basically,  the  most  frequently  used  aircraft 
structural  alloys  such  as  the  2000  and  7000  series  aluminums,  titanium  alloys  and  some 
steels  have  been  fully  characterized.  Of  course,  several  lesser  used  airframe  materials 
such  as  magnesium,  many  steels  and  a  few  aluminum  alloys  still  require  additional  testing 
to  quantify  crack  growth  and  fracture  behavior.  Mention  should  also  be  made  of  the 
classical  material  fatigue  or  crack  Initiation  computer  programs15.16  now  developed. 
Coupled  with  ctack  growth  analysis,  crack  initiation  serves  to  Indicate  areas  of  concern 
and  to  conduct  rapid  parametric  studies  of  the  effects  of  material  and  stress  level 
changes.  Such  studies  are  now  becoming  more  Important  at  the  ALCs  to  evaluate  the 
relative  benefits  of  potential  repairs.  Thus  usage  of  these  studies  should  Increase 
during  the  next  five  years  as  aids  In  quickly  formulating  force  management  decisions. 

FINITE  ELEMENT  MODELING 

"Man  Is  a  tool-using  animal  .  .  . 

Without  tools  he  is  nothing,  with  tools  he  is  all"  -  Thomas  Carlyle 

Probably  the  most  versatile  tool  presently  in  the  stress  analyst's  repertoire  is  finite 
element  modeling  (FEM).  As  was  the  caBe  with  DTA,  FEM  was  utilized  by  aircraft 
manufacturers,  ASD  and  AFFDL  engineers  well  before  its  use  spread  to  the  ALCs.  Now  the 
role  of  FEM  at  the  ALCs  differs  only  in  degree  from  its  usage  at  these  other  activities. 

By  the  very  nature  of  their  responsibilities,  the  ALCs  must  react  swiftly  to  structural 
questions.  Hence,  a  finite  element  model  must  necessarily  be  kept  to  a  size  commensurate 
with  the  time  constraint  of  the  given  situation.  With  that  caveat,  FEM  can  cover  a  gamut 
of  uses  at  the  ALCs.  The  primary  purpose  is,  of  course,  to  adequately  describe  the 
stresses  In  a  particular  structure  either  to  determine  the  effect  of  repairs  and 
modifications  or  to  calculate  crack  growth. 

The  partnership  between  the  ALCs  and  the  aircraft  manufacturers  is  especially  strong  in 
the  realm  of  large  finite  element  models.  Generally  speaking,  the  airframe  contractor  has 
a  much  larger  engineering  staff  and  far  more  extensive  computing  facilities.  For  this 
reason,  large  finite  element  models,  say  over  3,000  degrees  of  freedom,  are  usually  done 
under  contract.  This  Is  obviously  true  of  the  entire  airframe  coarse  finite  element 
models,  such  as  Figure  3,  which  are  constructed  In  order  to  obtain  internal  loads  for  the 
baseline  DTA  studies.  The  predominantly  used  approach  Is  to  apply  unit  loads  to  the  model 
and  evaluate  the  resulting  fractional  stresses  produced  in  each  element.  In  this  manner, 
s tress-to-load  ratios  or  influence  functions  are  obtained  which  directly  relate  external 
airframe  loads  to  Internal  structural  stresses  and  displacements.  Once  these  very  large 
coarse  models  are  transferred  to  the  ALC  they  can  then  be  used  to  provide  the  forces  and 
displacements  required  as  boundary  conditions  for  finer  detailed  models  created  at  the  ALC 
to  study  a  given  problem. 
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The  snaller  detailed  models  generated  at  an  ALC  satisfy  several  needs.  The  determination 
of  stress  Intensity  solutions  via  FEM  has  been  alluded  to  earlier  In  this  paper. 

Basically,  structural  features  with  complicated  geometry  and  load  transfer  lend  themselves 
to  models  employing  crack  tip  elements  to  derive  the  "Beta  factor"  for  the  crack  growth 
analysis.  Such  models  also  quickly  establish  critical  crack  lengths.  Even  without  the 
use  of  singularity  elements,  detailed  models  are  useful  for  investigating  the  local  stress 
reduction/redistribution  due  to  a  repair,  modification  or  failed  member.  These  stress 
results  can  then  be  applied,  either  as  changes  to  the  far  field  stress  spectra  or  as 
stress  to  load  ratios,  in  a  conventional  f 1 1 ght -by-f 1 1 ght  crack  growth  analysis.  Even 
when  cracking  has  not  been  observed  In-service  at  a  suspected  location,  detailed  modeling 
at  an  ALC  can  aid  In  deciding  on  the  potential  crack  paths  by  mapping  the  tensile  stress 
trajectories.  This  Is  often  necessary  to  locate  "hot  spots"  and  to  suggest  possible  NDI 
techniques.  Furthermore,  these  models  can  also  demonstrate  If  sufficient  load  carrying 
capability  still  remains  and  If  flight  restrictions  will  be  effective  In  alleviating  the 
situation.  Corrosion  grlndout  limits  are  also  established  more  accurately  by  using  FEM. 
Finally,  the  use  of  FEM  at  the  ALCs  Is  a  valuable  adjunct  to  flight  testing.  It  Is  often 
difficult  to  locate  accelerometers  or  strain  gages  at  the  precise  position  desired  for  a 
stress  analysis  due  to  the  physical  confinements  of  the  actual  structure.  The  finite 
element  model  provides  the  Interpolation  map  which  makes  possible  minimizing  expensive 
flight  tests. 

At  the  present  time,  FEM  at  the  ALCs  appears  to  be  focusing  on  the  use  of  NASTRAN, 
primarily  the  MACNEAL-SCHWENDLER  Company  (MSC)  version,  as  the  main  finite  element  code. 
This  Is  In  keeping  with  the  entire  aerospace  Industry's  current  direction.  Although  many 
major  mainframe  manufacturers  developed  their  own  programs  a  decade  ago  or  highly  modified 
the  early  versions  of  COSMIC  NASTRAN,  the  recent  trend  has  been  to  standardize  on 
MSC/NASTRAN.  From  an  ALC  point  of  view,  such  standardization  Is  quite  beneficial  since 
the  manpower  and  computation  limitations  at  an  ALC  preclude  adroitly  working 
simultaneously  with  several  different  finite  element  codes.  The  normal  transfer  of 
military  personnel  on  a  four  year  cycle,  as  well  as  the  routine  demands  of  other 
activities  on  both  civilian  and  military  engineers,  means  that  organizational  efficiency 
Is  best  served  by  having  only  one  large  finite  element  code  in  use  at  an  ALC.  Of  course, 
most  large  codes  have  dynamic,  aeroelastlc  and  buckling  capabilities  In  addition  to  static 
analysis  but  the  same  reasons  that  tend  to  obviate  doing  more  than  one  such  large  code 
also  tend  to  obviate  sloping  these  types  of  analyses  routinely  at  an  ALC.  The  more  likely 
event  would  be  to  contract  such  work  to  the  airframe  manufacturer. 

A  similar  focusing  trend  in  computer  hardware  acquisition  Is  also  discernible.  The 
tendency  is  toward  use  of  dedicated  supermini  computers  for  structural  analysis  with 
several  ALCs  having  or  obtaining  the  DEC  VAX  11/780.  As  was  pointed  out  in  reference  17, 
such  machines  provide  user-friendly  operational  characteristics  such  as  interactive 
operating  systems,  local  control  over  resources  and  turnaround,  and  high-speed  graphics 
but  at  the  price  of  being  considerably  slower  than  mainframes.  For  example,  one 
contractor  developed  entire  airframe  MSC/NASTRAN  model  which  took  30  minutes  to  run  on  the 
contractor's  mainframe  takes  nine  hours  to  run  alone  on  the  WR-ALC  VAX  11/780.  Of  course, 
such  runs  are  not  daily  occurrences  and  the  use  of  a  model  with  superelement  formulation 
can  Improve  such  run  times  significantly.  Nevertheless,  the  benefits  of  a  dedicated 
super-minicomputer  to  an  ALC  engineering  and  reliability  branch  now  appear  to  well 
outweigh  the  dl sad  van tages .  One  point  that  must  be  made,  however.  Is  that  regardless  of 
the  machine  chosen  by  an  ALC  there  will  always  be  a  significant  effort  in  software 
conversion  for  programs  written  for  other  machines.  In  spite  of  the  fact  that  Fortran  is 
almost  universally  used  for  scientific  programs,  there  will  always  be  machine  unique 
coding  that  causes  time  consuming  translation.  The  ALCs  are,  as  was  stated  earlier,  the 
beneficiaries  of  the  considerable  efforts  undertaken  by  ASD,  AFFDL  and  the  various 
manufacturers  but  much  of  that  work’s  software  still  had  to  be  converted  before  it  could 
be  used  at  an  ALC. 

In  contrast  to  the  finite  element  code  and  s upe r-mi nl compu t e r  utilization,  the  pre  and 
post  processor  graphics  hardware  and  software  arena  shows  great  diversity.  The  key  to  the 
rapid  construction  and  the  prompt  evaluation  of  the  results  of  detailed  finite  element 
models  at  an  ALC  lies  In  this  area.  Several  of  the  major  airframe  mnauf acturers  are 
developing  pre  and  post  processor  for  FEM  In  conjunction  with  their  computer  aided 
design/computer  aided  manufacturing  (CAD/CAM)  efforts.  Although  these  efforts  hold  great 
future  promise,  they  have  not  yet  reached  the  point  of  being  available  for  use  at  the 
ALCs.  In  aost  Instances,  they  are  written  for  use  Interactively  with  a  large  mainframe  or 
for  use  with  the  more  expensive  and  large  "smart"  terminals.  Presently,  the  ALCs  are 
Investigating  the  commercially  available  pre  and  post  processor  graphics  packages, 
primarily  PATRAN-G  and  SUPERTAB.  In  regard  to  hardware,  a  myriad  of  color  graphics 
terminals  are  now  on  the  market.  They  cover  a  wide  spectrum  of  features,  capabilities  and 
price  and  each  ALC  will  have  to  decide  which  best  serves  its  needs.  At  WR-ALC,  SUPERTAB 
and  TEKTRONIX  4105  color  terminals  were  selected  but  there  were  many  other  equally  good 
choices.  Currently,  there  does  not  seem  to  be  a  trend  toward  commonality  among  the  ALCs 
in  this  area. 

The  needs  of  the  ALCs  in  FEM  during  the  next  five  years  appear  somewhat  utopian  when 
stated  In  black  and  white.  The  greatest  FEM  deficiency  which  now  faces  an  ALC  Is  the 
laborous  and  slow  process  of  converting  blue  print  dimensions  to  a  model.  There  does  not 
appear  to  be  any  technology  on  the  horizon  to  replace  this  manual  effort.  The  employment 
of  technicians  or  engineering  aides,  such  as  undergraduate  engineering  students  in 
work/study  (co-op)  programs,  can  relieve  more  experienced  graduate  engineers  but  It  still 
does  not  condense  the  time  required.  The  problem,  or  challenge  If  you  will,  is  that  all 
of  the  aircraft  now  operational  were  designed  before  the  current  computer  aided 
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engineering  (CAE)  capabilities  were  developed*  Added  to  this,  data  storage  aethods  such 
as  microfilm  make  It  virtually  impossible  to  use  line  tracing  techniques  due  to  the 
unavoidable  distortions  In  replicating  the  original  scale  drawings*  Consequently,  the 
tedious  work  of  "reading"  the  drawings  and  "building"  the  model  with  Its  concomitant  time 
delays  appears  inescapable*  The  next  aircraft  designed  and  built  using  CAE  will  have 
electronic  data  bases  for  dimensions  which  will  make  FEM  both  quick  and  simple. 
Unfortunately,  It  18  unlikely  that  there  will  ever  be  sufficient  time  and  money  to  create 
such  electronic  data  bases  for  older  aircraft* 
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ELECTRONIC  DATA  BASES 

"Obviously,  a  man's  judgment  cannot  be  better  than 

the  information  on  which  he  has  based  it"  -  Arthur  Hays  Sulzberger 

The  Introduction  of  electronic  data  bases  for  aircraft  structural  Information  at  the  ALCs 
has  the  potential  to  markly  Improve  force  management  procedures  and  posture.  Airframe 
force  management  is  defined1**  as  the  specification  and  direction  of  Inspections, 
preventive  maintenance,  repairs,  modifications,  and  damage  assessments  required  to 
economically  prevent  structural  failure  and  preserve  the  strength  and  rigidity  of  the 
Individual  airframe  during  its  useful  life*  Obviously  a  crucial  electronic  data  base  for 
force  management  is  one  containing  crack  length  versus  flight  time  curves  calculated  by 
DTA  for  the  various  airframe  critical  locations.  Since  these  curves  were  calculated  using 
force  averages  for  mission  stress  spectra  and  mission  mix,  as  shown  In  Figure  1,  then  It 
Is  possible  to  adjust  these  curves  based  on  the  stresses  experienced  by  each  Individual 
aircraft.  The  process  which  accounts  for  individual  aircraft  flight  loads  and  operational 
environment  Is  known  as  the  Individual  Aircraft  Tracking  (IAT)  Program.  By  using  flight 
logs,  counting  accelerometers  and  strain  recorders;  the  specific  usage  of  each  aircraft 
can  be  determined,  and  consequently,  so  can  be  found  the  predicted  crack  growth  due  to 
that  usage.  Computerized  IAT  data  bases  of  this  type10  now  exist  based  on  crack  growth 
and  older  software  based  on  fatigue  initiation  are  being  converted  to  crack  growth.20 

The  next  step  to  be  taken  by  the  ALCs  In  using  the  computerized  IAT  electronic  data  bases 
Is  to  modify  the  computer  programs  so  that  the  system  is  capable  of  being  updated  by 
maintenance  feedback21  .  In  this  way,  future  maintenance  action  projections  can  account 
for  past  Inspection  results,  added  repairs,  and  airframe  modifications.  Feedback  from 
inspections  is  particularly  Important  since  the  crack  growth  curves  are  predicated  on  an 
assumed  Initial  flaw  size.  If  an  inspection  does  not  reveal  a  crack  at  a  particular 
location  then  analytically  this  means  the  location  did  not  have  an  Initial  flaw  as  large 
as  assumed.  Hopefully,  this  will  be  the  case  for  the  vast  majority  of  aircraft  Inspected 
and  the  crack  growth  curves  for  these  locations  can  be  reset  to  the  NDI  detectable  flaw 
size.  The  result  Is  a  shifting  of  the  crack  growth  curve,  as  shown  in  Figure  4  from 
reference  18,  to  a  higher  flight  hour  safety  limit.  Therefore,  credit  can  now  be  taken 
for  better  manufacturing  quality  than  could  be  assumed  in  the  baseline  DTA. 

The  IAT  computerized  data  base  should  also  be  able  to  supply  information  on  usage  severity 
by  home  base  or  mission  type.  Such  information  on  a  continuing  basis  allows  damage 
leveling  among  aircraft  by  switching  high  damage  aircraft  among  bases  or  by  having  certain 
aircraft  avoid  high  damage  Inducing  operations.  Additional  updates  to  the  force 
structural  maintenance  plan,  supplied  originally  by  the  airframe  manufacturers  as  part  of 
the  aircraft  procurement,  are  also  a  potential  result  of  the  Information  being  acquired  by 
the  IAT  program.  If  the  IAT  data  base  reveals  that  unanticipated  cracks  are  being  found 
and  reported  during  aircraft  Inspections  or  that  significant  changes  from  the  baseline  DTA 
stress  spectra  are  occurring  In  aircraft  operations,  then  the  aircraft  structural 
Inspection  schedules  should  be  changed  accordingly.  Ultimately,  the  optimum  airframe 
Inspection  schedule  for  a  particular  Individual  aircraft  tall  number  can  be  created  using 
the  IAT  data  base.  Of  course,  considerations  of  non-alrframe  Inspections  could  modify 
such  schedules  so  that  advantage  can  be  taken  of  aircraft  downtime  for  engine  overhaul  or 
avionics  repair. 

In  order  to  accomplish  the  tasks  possible  with  the  IAT  data  bases,  two  present  needs  must 
be  fulfilled.  First,  the  current  tracking  systems  must  be  Improved  significantly  to 
reduce  time  lags,  bad  data  and  excessive  manpower  requirements.  Second,  a  comprehensive 
computerized  system  must  be  developed  to  Identify  indlvicTual  aircraft  inspection 
requirements.  Such  a  system  should  be  capable  of  accounting  for  variations  in  usage 
severity  among  Individual  aircraft  as  well  as  for  peculiar  repairs  or  structural 
configurations  on  any  Individual  aircraft.  Fortunately,  work  is  now  progressing  on  both 
of  these  needs.  Flight  loads  data  recorders  are  now  In  development22*23  utilizing  solid 
state  microprocessor  technology.  Equipped  with  memory  and  data  editing  algorithms,  these 
recorders  can  be  "milked"  or  downloaded  via  portable  ground  Interrogation  devices  for 
terminal  transfer  to  the  appropriate  ALC.  A  computerized  IAT  system  is  now  being 
Implemented  at  WR-ALC  with  the  C-141  transport  as  the  prototype  aircraft.  Known  as  the 
Aircraft  Information  Retrieval  System  (AIRS),  It  will  have  approximately  10  years  of  data 
on  each  Individual  aircraft  residing  In  Its  data  base  at  any  time.  The  data  base  can  be 
accessed  from  special  terminals,  formatted  in  various  modes  and  used  for  trending  analysis 
with  graphical  displays.  One  such  IAT  data  base  operation  la  the  Usage  Simulation  and 
Evaluation  (USE)  program  which  provides  the  capability  to  evaluate  the  effect  of 
contemplated  mission  profiles  and  proposed  utilizations  on  Inspection  requirements  and 
damage  rate.  The  Inputs  and  outputs  of  these  operations  are  shown  In  Figures  5  and  6 
taken  from  reference  24. 
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RISK  ASSESSMENT 

"Take  calculated  risks.  That  Is  quite 
different  from  being  rash"  -  George  S.  Patton 

The  calculation  of  the  risk  of  structural  failure  Is  becoming  an  Item  of  keen  interest  and 
need  at  the  ALCs.  A  quantified  Indication  of  the  risk  Involved  with  a  particular  option 
should  provle  quite  useful  In  the  arduous  decision  making  process  that  often  occurs  In 
force  management.  The  work  of  Lincoln25  computes  the  single  flight  probability  of 
failure,  the  aircraft  failure  probability,  and  the  expected  number  of  failures  in  the 
force  provided  that  specific  Information  is  available  to  the  analyst.  This  information 
Includes  probability  density  functions  for  crack  length  and  stress,  critical  crack  length 
versus  stress.  Inspection  reliability,  crack  growth  versus  time  and  fastener  hole  reaming 
as  the  only  rework  decision.  Generally  speaking,  however,  all  of  this  Information  Is  not 
available  for  a  given  situation.  A  somewhat  similar  approach  recently  broached  by  Saff 
and  Forness  26  shows  promise.  Inspection  results  of  failed  and  cracked  components  are 
normalized  based  on  usage  severity.  The  normalized  lives  'of  the  cracked  components  are 
extrapolated  to  predicted  failure  lives  using  DTA  and  combined  with  the  actual  failure 
lives.  The  data  for  uncracked  and  uiifalled  components  Is  accounted  for  as  suspensions 
while  a  Welbull  statistical  technique  predicts  failure  life  distributions.  From  the 
Velbull  distribution  the  risk  of  a  structural  failure  can  then  be  found  for  any  point  In 
the  service  life  of  a  given  aircraft  or  set  of  aircraft.  Combining  this  technique  with 
the  DTA  and  IAT  data  bases  under  development  could  be  a  true  boon  to  the  SPMs  at  the  ALCs. 
Much  work  remains  to  be  done  but  this  appears  to  be  a  most  fruitful  area  for  efforts 
during  the  next  five  years. 


NEW  ADVANCED  STRUCTURAL  MATERIALS 

"Nothing  quite  new  Is  perfect"  -  Marcus  Tullius  Cicero 

The  advantages  of  advanced  composite  materials  of  higher  s t reng th- to-wel gh t  ratios, 
fatigue  and  corrosion  resistance  and  aeroelaatlc  tailoring  potential  are  well  recognized. 
Similarly,  the  metal  matrix  materials  are  also  widely  known  to  have  benefits  yet  to  be 
reaped.  As  these  new  advanced  structural  materials  gain  qreater  utilization  In  USAF 
aircraft  primary  structure,  the  ALCs  will  be  called  upon  to  repair  such  structure  and  to 
verify  the  repairs  by  analysis.  It  is  beyond  the  scope  of  this  paper  to  delve  Into  the 
various  failure  modes  or  repair  techniques  under  current  study  for  advanced  composites; 
there  have  been  several  recent  conferences  and  meetings  devoted  just  to  these  subjects  as 
given  in  references  27  to  29.  Suppor t abl 1 1 t y  of  composites  Is  now  being  Investigated 
within  AFLC  30,31  anj  afsc  has  contracted  for  studies  of  both  the  durability32  and  damage 
tolerance  33  of  composites  In  primary  structure.  It  Is  difficult  at  this  Juncture  to 
predict  the  ALC's  structural  analysis  needs  for  these  new  materials  but  It  appears  likely 
that  they  may  be  subs tantlal ly  greater  than  for  current  materials.  Of  course,  much  of  the 
present  methodology  such  as  finite  element  modeling  and  flight  loads  spectrum  development 
Is  readily  transf errable  but  much  fundamental  work  Is  still  underway  on  such  areas  as 
Impact  damage  and  repat rabl 1 1 ty  at  depot  and  field  levels. 


CONCLUDING  REMARKS 

"Forewarned  -  forearmed"  -  Miguel  De  Cervantes 

The  next  five  years  should  bring  great  strides  In  structural  analysis  capabilities  at  the 
ALCs.  Indeed,  such  advances  are  mandatory  If  force  management  Is  to  keep  pace  with  the 
requirement  to  maintain  maximum  operational  readiness.  The  former  Commander  of  AFLC, 
General  James  P.  Mullins,  has  stated  It  In  this  fashion,  "From  the  logistics  perspective, 
the  Interesting  thing  about  new  technology  Is  that  It  tends  to  feed  on  Itself,  generating 
greater  support  requirements  which,  In  turn,  demand  even  greater  use  of  technology. 
State-of-the-art  weapon  systems  today  need  state-of-the-art  logistics  support  and  lots  of 
It".  31  Such  state-of-the-art  support  can  only  come  about  by  close  cooperation  between  the 
ALCs,  ASD,  AFFDL,  and  the  various  airframe  manufacturers.  It  Is  not  difficult  to  project 
that  within  the  next  five  years  there  will  be  computer  data, links  between  an  ALC  and  Its 
respective  airframe  companies  to  provide  rapid  transfer  of  flight  spectra,  crack  growth 
evaluations  and  finite  element  analyses.  Much  needs  to  be  done  to  reduce  the  mundane 
drudgery  associated  with  many  present  analysis  techniques  and  personnel  at  all  levels 
within  the  affected  organizations  need  to  appreciate  the  new  vistas  that  can  be  opened  by 
their  cooperation.  Now  that  the  Air  Force  has  placed  supportabl 11 ty  on  an  equal  level 
with  performance  and  cost,  the  ALCs  will  have  to  assume  a  structural  analysis  role 
requiring  a  technical  prowess  heretofore  unnecessary.  There  Is  every  reason  to  believe 
that  the  challenge  will  be  met.  Perhaps  the  best  way  to  conclude  this  paper  Is  by 
suggesting  that  structural  analysis  at  the  ALCs  Is  becoming  the  fulfillment  of  these  words 
by  Alexander  Pope:  "Be  not  the  first  by  whom  the  new  are  Cried,  nor  yet  the  last  to  lay 
the  old  aside". 
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FIGURE  1.  FLOW  DIAGRAM  OF  SALIENT  FEATURES  OF  FLIGHT -BY-FLIGHT  FAT  I  CUE 
CRACK  GROWTH  ANALYSIS 
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FIGURE  5  C-141  AIRS  PROGRAM 


USAGE  SIMULATION  AW  EVALUATION  (USE)  PROGRAM  TONCEPT 


INPUTS  FROM  1AT  PROGRAM: 

BASE  Of  ASSIGNMENT 

FLIGHT  HOURS  BY  MISSIONS 

FLIGHT  HOURS  AT  LAST  INSPECTION 

FLIGHT  HOURS  TO  NEXT 
RECOMMENDED  INSPECTION 


C-141  USE. 
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FIGURE  6  C-141  USE  PROGRAM 
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The  design  of  complex  aerospace  vehicles  such  as  advanced  aircraft,  spacecraft  and  space  stations 
require  continually  increased  levels  of  detail  in  supporting  analyses.  Such  design  activities  require 
large  order  finite  element  models  and  excessive  computation  demands  in  both  calculation  speed  and  informa¬ 
tion  management.  Recent  advances  in  data  base  management  and  supercomputer  technology  provide  the  oppor¬ 
tunity  to  upgrade  current  structural  analysis  capabilities.  Most  existing  major  structural  analysis  soft¬ 
ware  systems  were  designed  ten  to  twenty  years  ago  and  have  been  optimized  for  current  computers.  Such 
systems  often  are  not  well  structured  to  take  maximum  advantage  of  the  recent  and  continuing  revolution  in 
computing  capabilities  such  as  distributed  processing,  information  management,  parallel  processing  and 
expert  systems  which  are  needed  to  eupport  the  design  of  the  next  generation  of  aerospace  vehicles. 

This  paper  discusses  some  research  carried  out  over  the  past  ten  years  in  engineering  data  baee  man¬ 
agement  and  parallel  computing  to  suggest  soma  opportunities  for  research  toward  the  next  generation  of 
structural  analysis  capability.  The  paper  is  based  on  experiences  in  data  base  management  associated  with 
the  IPAD  project  and  in  parallel  processing  associated  with  the  FBM  project,  both  sponsored  by  NASA. 
Using  these  results,  several  areas  are  identified  as  needed  research  to  achieve  a  next  generation  struc¬ 
tural  analysis  capability.  Also  included  is  a  near  term  strategy  for  a  distributed  structural  analysis 
capability  based  on  relational  data  base  management  software  and  parallel  computers  which  could  serve  as  a 
baseline  for  evolving  toward  a  future  structural  analysis  system. 


The  design  of  complex  aerospace  vehicles  such  as  advanced  aircraft,  spacecraft  and  spacestetions 
requires  continually  increased  levels  of  detail  in  supporting  analyses.  For  example,  requirements  make  it 
necessary  and  technology  advancements  make  it  feasible  to  consider  in  dynamic  analyses  the  combined  ef¬ 
fects  of  such  things  as  composite  materisls,  multidisciplinary  interaction,  three  dimensional  geometry  and 
nonlinear  behavior.  Including  such  effects  in  complex  structural  problems  may  require  large  order  finite 
element  models  and  excessive  computational  demands  in  both  calculating  speed  and  information  management. 
At  the  same  time  most  structural  analysis  syatsms  were  designed  ten  to  twenty  years  ago  (Fig.  1)  and  have 
been  optimised  for  current  computers.  Such  systems  often  are  not  well  structured  to  take  maximum  advan¬ 
tage  of  the  recent  and  continuing  revolution  in  computer  capabilities  in  such  areas  as  distributed  pro¬ 
cessing,  information  management,  parallel  computation,  and  expert  systems,  which  are  needed  to  support  the 
design  of  the  next  generation  of  aerospace  vehicles  (Fig.  2).  The  above  vehicle  requirements  combined 
with  the  age  of  structural  analysis  systems  suggest  ths  need  to  advance  the  technology  toward  a  new  gener¬ 
ation  of  structural  analysis  capability. 

This  paper  discusses  some  research  carried  out  over  the  past  ten  years  in  the  two  areas  of  engineer¬ 
ing  data  base  management  and  parallel  computing  to  suggest  some  opportunities  for  research  toward  the  next 
generation  of  structural  analysis  capability.  The  paper  is  based  on  experiences  in  data  base  management 
resulting  from  the  IPAD  (Integrated  Programs  for  Aerospace-Vehicle  Design)  project  (refs.  1-3)  and  in 
parallel  processing  resulting  from  the  FBM  (Finite  Rlement  Machine)  project  (ref.  39),  both  sponsored  by 
NASA.  Included  is  a  brief  suamary  of  work  from  each  project  together  with  a  proposed  near  term  strategy 
for  incorporating  these  capabilities  into  a  software  framework  to  serve  as  the  baseline  for  a  future 
structural  analysis  system. 


A  key  to  Improved  industry  productivity  is  the  affective  management  of  engineering  information.  To 
stimulate  advancement  in  this  area  a  Joint  NASA/Navy/Industry  project  designated  Integrated  Programs  for 
Aerospace-Vehicle  Design  (IPAD)  was  carried  out  from  1970-1984  with  the  goal  of  raising  aerospace  produc¬ 
tivity  through  advancement  of  technology  to  integrate  and  manage  information  involved  in  the  design  and 
manufacturing  process  (Fig.  3).  The  IPAD  research  was  guided  by  an  Industry  Technical  Advisory  Board 
(ITAB)  composed  of  over  100  representatives  from  aerospace  and  computer  companies  (Fig.  4). 

The  IPAD  project  developed  prototype  computer  software  to  meet  many  CAD/CAM  information  management 
requirements  (refs.  1-4).  Boms  of  the  basic  requirements  driving  CAD/CAM  systems  development  (refs.  S-21) 
Include  (Figure  5)i  (1)  accommodate  many  different  views  of  data  from  a  variety  of  users  and  computing 
storaga  devices)  (2)  allow  many  levels  of  data  descriptions  to  support  a  wide  variety  of  engineering  or¬ 
ganisations  and  tasks)  (3)  permit  easy  changes  in  data  definition  as  work  progresses)  (4)  allow  data  to  be 
distributed  over  networks  of  computers  of  various  manufacture)  (5)  permit  data  definitions  to  be  readily 
extended  as  needs  arise)  (6)  store  and  manipulate  geometry  information)  (7)  embody  adequate  configuration 
management  features)  and  (8)  provide  extensive  capability  to  management  information  describing  stored 
data.  The  IPAD  approach  taken  is  to  conduct  appropriate  research  and  develop  prototype  software  for  a 
future  network  of  computers  (refs.  22-24).  To  provide  the  required  CAD/CAM  functionality,  and  yet  meet 
software  performance  requirements,  data  base  management  is  staged  at  two  or  more  levels  with  different 
software  capabilities  needed  for  both  the  local  (user)  level  and  global  (project)  level  (Fig.  6).  With 
such  a  tlsrsd  data  base  management  approach,  today's  inconvenient  file-oriented  procedures  can  be  replaced 
by  future  procedures  (Fig.  7)  where  convenient  user  languages  efficiently  create,  store,  manipulate,  ec- 
cess,  and  control  information  in  accordance  with  CAD/CAM  requirements. 
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prototype  software  was  developed  under  the  IPAD  project  at  both  the  local  and  global  levels.  A  sys¬ 
tem  denoted  Relational  Information  Management  (RIM)  was  developed  for  local  level  data  management.  RIM  Is 
based  on  the  highly  flexible  relational  models  which  organise  and  manage  engineering  and  scientific  infor¬ 
mation  according  to  tables  and  relationships  among  tables.  Its  features  include  interactive  queries, 
report  writer,  and  FORTRAN  interface.  RIM  was  first  operational  in  1979  and  is  now  a  mature  system.  In 
1981,  it  served  as  a  critical  information  management  capability  to  support  NASA  Investigations  (ref.  25) 
of  the  integrity  of  30,000  tiles  on  the  space  shuttle  (Fig.  8),  The  success  of  RIM  in  such  evaluations 
has  led  to  its  continued  development  and  enhancement  by  government  and  industry  (Fig.  9).  A  public  Ver¬ 
sion  5.0  is  available  from  COSMIC *  for  CDC,  IBM,  DEC,  UNIVAC,  PRIME,  and  Karris  computers.  commercial 
organisations  have  continued  to  enhance  RIM  and  now  provide  compatible  RIM  derivative  software  (e.g., 
BCS/RIM  and  MicroRIM)  and  associated  maintenance  and  support  for  such  software  operational  on  a  wide  range 
of  computers  (frost  personal  computers  to  super  computers).  Commercial  versions  of  RIM  are  being  used 
extensively  by  industry  (refs.  26-29) ,  and  attendant  RIM  User  Groups  have  been  established  to  coordinate 
mutual  needs.  NASA  used  RIM  as  the  common  data  management  system  (Fig.  10)  to  integrate  several  engineer¬ 
ing  analysis  programs  (Fig.  11)  through  the  development  and  application  of  a  prototype  system  denoted 
Prototype  Integrated  Design  System  (PRIDE)  (refs.  49,  50).  Through  use  of  the  RIM  data  communication 
features  the  PRIDE  system  includes  a  distributed  data  base  capability  across  a  network  of  heterogeneous 
computers  (Fig.  12). 

IPAD  research  also  led  to  developaient  of  a  global  data  base  management  system  denoted  IPAD  Informa¬ 
tion  Processor  (IPIP).  The  approach  taken  In  IPIP  was  to  provide  the  capability  within  one  system  to 
manage  Information  composed  of  a  wide  variety  of  information  structures  including  hierarchical,  network, 
relational,  and  geometric.  The  IPIP  approach  uses  multiple  levels  of  information  formats  (schemata)  to 
permit  unlimited  reorganization  of  information  as  work  progresses  (Fig.  13).  Each  schema  is  connected  to 
other  schemata  via  a  general-purpose  mapping  capability  (language).  IPIP  is  a  new  concept,  still  in  test 
and  evaluation  phases,  and  is  currently  operational  on  a  CDC  computer.  Its  approach  to  management  of  geo¬ 
metric  data  is  a  unique  and  important  concept  which  could  be  very  important  to  future  integration  of  de¬ 
sign  and  manufacturing.  A  critical  technical  challenge  to  IPIP  development  has  been  to  provide  the  high 
degree  of  engineering  user  flexibility  and  yet  achieve  acceptable  response  times.  In  late  1983  a  test 
system  which  has  user  responses  for  test  problems  of  less  than  0.5  seconds  was  provided  to  selected  ITAB 
organizations  to  support  its  evaluation.  IPIP  has  also  been  established  by  one  computer  vendor  as  an  "as 
is"  product  and  limited  support  is  provided  by  the  vendor  for  its  installation  and  evaluation.  IPAD  re¬ 
sults  to  date  in  defining  CAD/CAM  data  management  requirements  and  in  developing  prototype  software  have 
helped  stimulate  development  of  commercial  CAD/CAM  data  management  software  (refs.  30-33),  and  several 
computer  vendors  plan  release  in  1984  of  relational-type  data  management  systems  which  address  many  of  the 
CAD/CAM  requirements  identified  in  IPAD  research.  IPAD  results  have  also  helped  stimulate  infUBion  of 
data  base  management  technology  into  university  engineering  research  (refs.  34-36). 

A  critical  CAD/CAM  requirement  not  yet  contained  within  any  available  or  planned  commercial  data 
management  system  is  the  ability  to  efficiently  manage  geometry  information  in  concert  with  other  engi¬ 
neering  data  (Fig.  14).  Through  use  of  the  multischema  capability,  IPIP  provides  the  first  approach  to 
management  of  geometry  information  within  a  data  management  system  (refs.  13,  14).  The  IPIP  approach 
provides  software  capability  to  create  on  top  of  the  basic  geometric  data  an  information  structure  having 
an  unlimited  number  of  geometric  descriptions  (schemata).  One  geometry  schema  includes  the  evolving  geo¬ 
metry/graphics  standard.  Initial  Graphics  Exchange  Specifications  (IGES).  This  IPIP  information  structure 
concept  opens  the  door  for  convenient  integration  of  geometric  information  with  other  types  of  information 
associated  with  a  CAD/CAM  development  process  (Fig.  15).  An  evaluation  of  the  IPIP  geometry  concept  is 
now  underway,  and  comparisons  are  being  made  with  other  approaches  in  which  management  of  the  geometric 
data  takes  place  outside  the  basic  data  base  manager. 


The  complex  structural  analyses  required  for  advanced  aerospace  vehicle  design  may  require  large 
order  finite  element  models  and  very  large  scale  computations.  Design  of  such  vehicles  will  require  in 
some  cases  effective  computer  speeds  greater  them  10^  MFLOPS  (million  floating  point  operations  per  sec¬ 
ond)  for  timely  results.  These  speeds  are  well  beyond  the  capabilities  of  current  sequential  computers. 

Projected  advances  in  computer  technology  indicate  signlficemt  increases  in  effective  calculation 
speed  will  be  available  in  the  1990's  through  computer  architectures  consisting  of  arrays  of  processors 
operating  concurrently  on  different  tasks  (refs.  37,  38).  As  indicated  in  Figure  16,  such  advanced  compu¬ 
ters  denoted  MIND  (multiple  instruction,  multiple  data)  computers  have  the  potential  for  increasing  effec¬ 
tive  calculation  speeds  by  several  orders  of  magnitude.  The  key  to  achieving  this  increased  speed  for 
structural  analysis  is  the  selection,  development  and  implementation  of  appropriate  numerical  algorithms 
which  take  advantage  of  the  concurrent  computation  features  of  this  new  generation  of  computers.  Use  of 
existing  conventional  algorithms  and  software  will  not  realize  the  full  potential  of  these  new  MIND  compu¬ 
ters  i  new  algorithms  are  needed  which  support  structural  calculations  on  concurrent  computers. 

8tudias  carried  out  under  the  FEM  project  have  included  investigations  of  several  numerical  analysis 
algorithms  for  MIND  computers  and  assessed  the  increase  in  computation  speed  relative  to  a  sequential 
computer  Implementation.  Two  algorithms  studied  include  eigenvalue  determination  and  numerical  integra¬ 
tion  methods  which  have  application  to  free  vibration  and  transient  response  analysis  of  complex  finite 
element  models.  This  section  summarises  the  methods,  discusses  concurrent  implementation  criteria,  and 
provides  results  from  application  of  the  methods  to  test  problems  on  an  experimental  MIMD  computer. 

Implementation  on  an  Experimental  MI HD  Oomputar 

The  total  hardware/softwara  system  must  be  taken  into  consideration  when  developing  and  implementing 
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a  concurrent  algorithm.  The  implementation  criteria  that  influence  the  efficiency  of  an  algorithm  include 
the  amount  of  computation  versus  the  amount  of  communication  in  a  given  problem,  the  balance  of  workload 
among  the  processors,  the  communication  paths  and  synchronization  delays,  and  the  size  of  a  problem  rela¬ 
tive  to  the  mxnb«r  of  processors  used.  The  flow  of  the  algorithm  must  be  analyzed  to  identify  those  cal¬ 
culations  which  must  be  sequential  and  those  which  can  be  done  in  parallel.  Efficient  algorithms  typical¬ 
ly  maximize  parallel  calculations,  minimize  sequential  calculations,  minimize  communication,  and  partition 
tasks  onto  a  processor  array  so  that  the  communication  paths  are  most  effective. 

The  computer  hardware/ software  system  used  to  support  this  study  was  the  Pinite  Element  Machine  (FBI) 
(fig.  17),  an  experimental  mimd  computer  developed  at  the  NASA  Langley  Research  Center  to  support  parallel 
processing  research  for  structural  applications  (ref.  39).  The  PEM  design  is  an  array  of  microprocessors 
connected  together  by  up  to  12  local  links  plus  a  global  bus  (fig.  18).  Each  processor  has  its  own  memory 
and  can  be  programmed  to  perform  calculations  independently.  A  small  mini  consul  ter  acts  as  a  front-end 
controller  where  programs  are  coded  and  compiled. 

Through  use  of  custom  designed  system  software  (refs.  40,  41),  PEM  programs  are  sent  from  the  con¬ 
troller  to  the  processor  array.  While  the  program  is  executing  on  the  array,  the  software  provides  con¬ 
trol  and  runtime  monitoring.  When  execution  is  completed,  output  is  sent  back  to  the  controller.  The 
processors  can  run  in  two  modes:  synchronous  or  asynchronous.  In  the  synchronous  mode,  input  is  queued  in 
order  in  the  receiving  processor  until  it  is  used.  Thus,  if  one  processor  needs  information  from  another 
processor,  execution  is  halted  until  such  information  is  received.  In  an  asynchronous  mode,  data  sent  to 
one  processor  can  be  written  over  by  subsequent  data.  In  some  algorithms,  this  approach  is  desirable,  as 
the  new  information  is  more  meaningful.  The  FEM  configuration  used  for  this  study  was  limited  to  eight 
asynchronous  processors  connected  together  by  eight  local  links  and  by  a  global  bus. 

Inverse  Power  Method  for  Eigenvalue  Analysis 

The  approach  used  for  eigenvalue  and  eigenvector  determination  is  the  inverse  power  method  tailored 
to  take  advantage  of  concurrent  processing  capabilities.  The  inverse  power  method  is  an  iterative  method 
often  used  for  determining  vibration  frequencies  and  mode  shapes  for  large  order  structural  problems 
(ref.  42  and  43).  It  is  particularly  useful  since  it  retains  the  original  form  of  the  stiffness  matrix, 
its  associated  sparsity  and  its  numerical  accuracy,  as  well  as  any  matrix  decompositions  previously  ob¬ 
tained.  For  a  brief  summary  of  the  method  consider  the  following  eigenvalue  problem: 

K  X  -  X  M  X  (1) 

where  K  and  M  are  the  symmetric  stiffness  and  mass  matrices,  respectively,  and  X  is  the  eigenvalue  repre¬ 
senting  the  square  of  the  frequency.  The  inverse  power  method  iterates  through  the  sequence: 

X  V  r+l  -  X  M  V*  ( 2 ) 

where  r  denote*  the  rth  iteration  and  V*  the  current  estimate  of  the  eigenvector,  the  method  converges  to 
the  lowest  X  and  associated  eigenvector.  Larger  eigenvalues  and  associated  eigenvectors  can  be  obtained 
through  use  of  orthogonality  to  "sweep  out"  the  effects  of  the  lower  eigenvectors  from  the  Vr .  For  exam¬ 
ple,  the  method  converges  to  the  next  lowest  X  and  associated  eigenvector  if  the  assumed  vector  V1  la 
taken  aa 


V1  -  V  -  c,X,  (3) 

where  V  is  an  arbitrary  vector  and  is  the  participation  of  the  first  eigenvector  in  V  «*nd  is  given 
by 
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Convergence  of  the  method  can  be  assessed  through  comparison  of  all  elements  of  the  two  vectors  Vr+ ' 
to  V*  or  through  comparison  of  their  norms.  The  converged  eigenvalue  can  be  determined  through  uee  of 
the  Rayleigh  Quotient  associated  with  the  eigenvector  x^»  that  is 


X 


(5) 


The  method  can  be  used  to  obtain  the  X  closest  to  a  reference  value  8.  (denoted  a  "shift  parameter")  by 
inserting  a  shift  in  the  eigenvalue  scale.  In  equation  (2)  let:  ■* 

X  -  8j  ♦  I  (6) 

which  results  in 

(K  -  8^  N)  V*"  -  X  M  V1  (7) 

In  the  concurrent  implementation  of  the  invars,  power  method,  shifts  are  used  and  each  processor 
calculates  the  eigenvalues  In  the  neighborhood  of  a  specified  reference  value  pj  .  Each  processor  then 
obtains  s  given  number  of  eigenvalues  in  the  range.  An  eigenvalue  spectrum  ana  the  concurrent  inverse 
power  method  mapped  onto  four  processors  are  illustrated  in  Figure  19.  The  jth  processor  calculates  the 
eigenvalue,  in  the  neighborhood  of  8j  «  If  th.  Bj  are  too  close  to  each  other,  the  results  from  the  re¬ 
spective  neighboring  processors  may  overlap  whan  several  eigenvalues  are  obtained  in  each  processor. 
Thera  is  a  trade  off  between  the  number  of  eigenvalues  to  be  calculated  near  a  reference  Bj  value  and  the 
selection  of  a  new  Bj.  Th#  decision  to  select  a  new  Bj  or  to  calculate  more  eigenvalues  for  a  given 
Bj  can  be  controlled  either  by  the  user  or  by  an  appropriate  executive  algorithm.  The  user  controlled 
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approach  to r  decision  making  is  summarized  here  and  further  details  on  an  executive  controlled  approach 
are  given  in  ref.  44.  The  major  calculation  steps  area 

1.  Assign  to  aach  processor  the  task  of  calculating  eigenvalues  near  a  specific  reference  eigen¬ 
value. 

2.  use  the  inverse  power  method  with  shifts  to  calculate  a  sequence  of  eigenvalues  and  associated 
eigenvectors  closest  to  a  reference  value.  Use  the  Rayleigh  quotient  to  refine  eigenvalue  re¬ 
sults  . 

3.  Establish  a  control  procadura  for  the  concurrent  calculations  that  is  either:  (1)  user  directed: 
or  (2)  directed  through  executive  software  which  can  be  assigned  to  one  of  the  processors  as  a 
part  of  its  workload.  Either  approach  should  focus  on  tracking  the  eigenvalue  results  from  the 
various  processors,  selecting  parameter  ranges  and  balancing  processor  workload. 

fbr  a  user  controlled  approach,  aach  processor  executes  the  inverse  power  method  independently  and 
asynchronously.  Each  processor  is  given  a  different  shift  parameter  8j  and  assigned  the  task  of  solving 
for  a  given  number  of  eigenvalues  closest  to  fij  and  associated  eigenvectors.  This  approach  is  useful  for 
the  user  who  does  not  need  all  eigenvalues  but  wants  eigenvalues  in  several  specified  ranges.  Because 
there  is  no  communication  requirement  among  processors,  a  significant  speedup  is  achieved  compared  to 
using  the  same  algorithm  sequentially.  Bach  processor,  however,  takes  a  different  computation  time  to 
solve  for  its  assigned  number  of  eigenvalues. 

Total  time  to  complete  a  solution  phase  is  the  time  for  the  processor  with  the  largest  workload  to 
complete  its  tasks.  Since  each  processor  works  independently,  there  is  no  communication  or  synchroniza¬ 
tion  overhead,  but  there  is  an  imbalance  in  workload.  Furthermore,  there  is  no  mechanism  other  than  user 
insight  to  ensure  against  duplicate  or  redundant  eigenvalue  calculations.  The  approach  could  be  useful  in 
a  multiprogramming  environment  where  other  user  tasks  could  be  performed  on  any  idle  processor.  An  execu¬ 
tive  controlled  approach  discussed  in  refarance  8  provides  a  more  convenient  automated  search  strategy  for 
balancing  workload  and  determining  eigenvalues  within  a  range,  but  it  also  results  in  some  increase  in 
overhead. 


Application  of  Concurrent  Inverse  Power  Method 

To  evaluate  the  concurrent  inverse  power  method,  a  test  problem  was  solved  on  an  array  of  FEM  proces¬ 
sors.  The  test  problem  was  chosen  to  fit  the  memory  constraints  of  the  Finite  Element  Machine,  and  embody 
some  of  the  aspects  of  large  order  structural  vibration  problems  which  impact  concurrent  implementation. 
For  example,  the  stiffness  matrix  is  sparse,  there  are  groups  of  closely  spaced  frequencies,  and  the  rate 
of  convergence  of  the  inverse  power  method  varies  over  the  frequency  range - 

The  test  problem  (Fig.  20)  deals  with  the  flexural  vibration  of  a  long  beam  simply  supported  with  16 
uniformly  spaced  supports.  The  beam  mass  is  assumed  to  be  lumped  at  the  supports  with  a  rotational  iner¬ 
tia  of  m  «  1.0  at  each  support.  The  beam  is  modeled  by  15  finite  elements  with  one  element  between  each 
support.  Since  the  lateral  displacements  are  constrained  to  be  zero,  the  finite  element  degrees  of  free¬ 
dom  are  the  beam  rotations  at  each  of  the  16  supports.  The  beam  stiffness  EI«1 .0  for  all  segments  except 
the  firet  where  EI«2.0.  The  first  three  mode  shapes  and  frequencies  are  shown  in  Fig.  21. 

In  the  solution  procedure,  each  proceesor  was  assigned  the  task  of  obtaining  a  specific  number  of 
eigenvalues  in  an  eigenvalue  range  to  attempt  to  balance  the  workload.  Specifically  the  sixteen  total 
eigenvalues  sought  were  assigned  equally  among  the  working  processors:  e.g.,  two  processors  were  assigned 
to  find  eight  eigenvalues  each,  four  to  find  four  each,  and  eight  to  find  two  each.  The  solution  times 
for  each  of  the  cases  are  given  in  Table  1.  Since  each  processor  works  independently,  there  is  no  commu¬ 
nication  or  synchronisation  overhead  in  the  calculations.  There  is,  however,  an  imbalance  in  the  work¬ 
load,  as  shown  by  the  timing  results  in  Table  1.  For  example,  when  only  two  processors  are  operating, 
each  solving  for  eight  eigenvalues,  the  first  processor  operates  for  210  seconds  while  the  second  operates 
for  192  seconds.  The  sequential  algorithm  requires  402  seconds  to  solve  the  problem;  thus  there  is  a 
"speedup''  in  calculation  time  of  1.9.,  where  speedup  is  the  ratio  of  sequential  calculation  time  (402 
sec.)  to  concurrent  computer  calculation  time  (210  sec.).  If  processor  workloads  are  balanced  and  all 
processors  operate  at  maximum  efficiency,  the  speedup  is  proportional  to  the  number  of  processors.  This 
result  is  denoted  in  the  extreme  right  column  of  Table  1(a)  as  the  theoretical  limit  for  speedup.  Meas¬ 
ured  computing  "speedupa"  for  the  test  problem  are  shown  in  Figure  22.  The  speedup  results  for  the  test 
problem  appear  representative  of  concurrent  processing  speedups  achievable  for  large  order  eigenvalue 
problems  through  user-controlled  task  assignments  for  the  inverse  power  methods.  Other  examples  and  im¬ 
provements  to  the  method  are  given  in  ref.  44. 


Structural  Dynamic  Response  Calculations 

As  a  second  example  consider  the  dynamic  response  of  a  discrete  structure  subjected  to  transient 
forces.  In  general  for  a  lumped  mass  formulation  of  a  finite  element  or  finite  difference  structural 
model,  the  acceleration  for  each  degree  of  freedom  for  aach  structural  node  is  a  function  of  all  displace¬ 
ments,  velocities  and  time.  In  the  concurrent  computer  implementation  (ref.  45,  46),  the  m  equations  of 
motion  can  be  distributed  over  n  processors.  A  typical  distribution  of  m  equations  of  motion  is 
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where  is  the  displacement  of  the  ith  degree  of  freedom  and  a  dot  denotes  differentiation  with  respect 
to  time*  If  me  is  a  multiple  of  n ,  there  is  an  equal  distribution  of  the  computational  load*  Otherwise, 
the  work  load  should  be  judiciously  balanced  to  miimize  processor  idle  time  and  increased  overhead. 


A  common  procedure  for  integrating  dynamic  equations  is  the  Newmark-Beta  method  (ref.  47).  The  ori¬ 
ginal  formulation  does  not  use  matrix  inversion  but  calculates  new  accelerations  iteratively.  This  formu¬ 
lation  was  chosen  for  this  study  to  maximize  parallelism  of  the  algorithm.  The  m  equations  of  motion  are 
distributed  and  solved  on  n  processors  ( 1 . e . ,  iw*n)  as  indicated  in  Figure  23.  All  processors  perform 
identical  functions  (same  software)  and  act  as  "integration  engines."  Moving  from  t  to  t+At,  each  pro¬ 
cessor  begins  with  an  assumed  acceleration  for  each  assigned  degree  of  freedom.  The  corresponding  first 
derivatives  and  displacements  are  calculated  using  the  following  equations 

w^t+At)  -  ii(t)+(wi(t)+wi(t+At) )  t/2  (1) 

w^ (t+At)  -  w1(t)+Atw1(t)+At2(wi(t+At)b+wi(t) (0.5-b) )  (2) 

where  b- 1/4  (trapezoidal  integration) . 


The  computation  is  then  interrupted  so  that  each  processor  can  communicate  results  for  its  assigned 
degrees  of  freedom  to  its  neighboring  processors.  flie  accelerations  are  then  computed  and  compared  with 
the  assisted  accelerations.  If  a  given  convergence  criterion  for  the  assigned  degrees  of  freedom  is  met, 
then  "local  convergence"  is  achieved.  The  computations  are  interrupted  again  to  check  for  convergence  of 
all  processors  (i.e.,  global  convergence)  by  using  a  flag  network  that  sets  a  flag  on  each  converged  pro¬ 
cessor  and  sends  its  status  to  other  processors.  If  either  the  local  or  the  global  convergence  test 
fails,  each  processor  uses  the  current  calculated  value  as  the  assumed  acceleration  and  repeats  the  compu¬ 
tations.  When  global  convergence  is  met,  all  processors  simultaneously  proceed  to  the  next  time  step. 

The  concurrent  solution  algorithm  was  applied  to  sample  dynamic  response  problems,  the  finite  element 
analysis  of  a  two-dimensional  beam  grillage  under  a  uniform  step  load  at  its  nodal  points  and  simply  sup¬ 
ported  at  the  boundaries  (Fig.  24).  Typical  displacement  responses  are  shown  on  the  lower  right  of  Figure 
24.  The  primary  computational  results  of  interest  are  the  times  to  calculate  the  structural  response  on  a 
varied  number  of  processors.  The  computational  speedup  derived  from  the  concurrent  processing  approach 
compared  to  the  sequential  approach  can  then  be  computed.  The  computational  speedup  is  defined  as  the 
computation  time  to  calculate  results  on  one  processor  divided  by  the  computation  time  to  calculate  the 
same  results  on  n  processors. 


the  computational  speedups  versus  the  number  of  processors  for  the  beam  grillage  problem  is  shown  in 
Figure  25.  The  theoretical  maximum  speedups  would  be  the  Bpeedups  if  there  were  no  overhead  for  concur¬ 
rent  processing.  Thus,  the  theoretical  computational  speedups  are  equal  to  the  number  of  processors  used. 
The  computational  speedups  for  solving  the  beam  grillage  problem  using  24  and  48  equations  are  shown  is 
Figure  9.  For  this  example,  there  is  a  speedup  of  up  to  7.36  using  eight  processors.  The  lack  of  maximum 
efficiency  in  the  speedup  is  due  to  several  factors.  For  example,  since  the  transferral  and  receipt  of 
data  are  not  Instantaneous,  communication  is  one  of  the  factors  that  contributes  to  the  overhead.  For 
iterative  methods,  it  is  necessary  to  synchronize  the  processors  before  making  convergence  checks,  which 
creates  another  source  of  overhead.  In  addition,  there  is  overhead  from  establishing  looping  parameters 
and  indices  identifying  processors  uniquely  and  from  nonparallel  coding.  The  results  suggest  that  future 
concurrent  processing  computers  hold  the  promise  for  significant  speedups  in  computing  capabilities  to 
support  large  order  nonlinear  dynamic  analyses  (Fig.  26). 


mown  ftiambi  worn  row  wenm  ubltsis  nwn 

The  results  of  refs.  37  and  48  indicate  that  future  structural  analysis  software  systems  should  be 
restructured  to  be  modular  in  algorithms,  software  structure  and  hardware  implementation  (Fig.  27).  Un¬ 
fortunately,  such  an  approach  is  a  long-term  solution  which  requires  redesign  and  coding  of  a  software 
base  at  the  same  time  the  hardware  base  is  changing  rapidly  and  alternatives  are  growing.  Research  is 
needed  in  many  areas  to  facilitate  the  develoimnnt  (Fig.  28). 

A  strategy  which  is  based  on  an  extension  of  the  PRIDE  distributed  data  base  approach  may  be  a  useful 
approach  to  facilitate  evolution  to  the  future.  The  key  is  the  data  base  management  approach.  Figure  29 
illustrates  an  approach  where  the  key  integrater  is  a  multimachine  flexible  data  base  management  capabi¬ 
lity  such  as  RIM.  This  concept  recognizes  the  need  for  a  wide  range  of  computing  processors  to  support 
engineering  calculations.  The  processors  may  range  from  workstations  to  mainframes  and  include  widely 
different  sequential,  concurrent,  and/or  symbolic  processors.  cn  each  processor  is  installed  a  common 
relational  type  data  base  manager  and  executive  which  have  the  same  user  functions  and  information  format. 
The  user  controls  transfer  of  information  among  processors  as  well  as  the  sequence  of  major  calculation 
steps.  Each  processor  then  carries  out  its  functions  and/or  applications  as  appropriate.  Data  is  moved 
among  processors  conveniently  in  a  standard  user-oriented  format  and  transformed  to  other  required  formats 
as  required.  The  relational  data  base  management  features  facilitats  the  data  transformation  and  existing 
application  programs  are  retained  on  the  processor  best  suited  for  their  use.  New  applications  which  may 
be  symbolic,  sequential,  and/or  concurrent  processor  based  can  be  developed  and  integrated  into  the  system 
as  appropriate  and  modeling  and/or  graphics  capabilities  generated  on  other  processors  can  be  easily  used. 

This  approach  is  easily  lmplementable  and  provides  a  good  strategy  for  using  existing  application 
programs  in  both  structural  analysis  and  other  disciplines.  As  upgraded,  more  modular  applications  soft¬ 
ware  systems  are  developed  they  can  be  incrementally  added  to  the  system  in  an  evolutionary  fashion.  As 
relational  type  data  base  management  systems  evolve  with  improved  performance,  these  can  be  readily  inte¬ 
grated  into  the  total  system.  As  new  hardware  evolves,  the  key  new  step  is  the  installation  of  the  appro¬ 
priate  executive  and  data  base  manager  on  the  new  hardware. 
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The  design  of  complex  aerospece  vehicles  such  as  advanced  aircraft,  spacecraft  and  space  stations 
requires  continually  increased  levels  of  detail  in  supporting  analyses.  Such  design  activities  require 
large  order  finite  element  and/or  finite  difference  models  and  excessive  computation  demands  in  both  cal¬ 
culation  speed  and  information  management.  Recent  advances  in  data  base  management  and  supercomputer 
technology  provide  the  opportunity  to  upgrade  current  structural  analysis  capabilities.  Most  existing 
structural  analysis  software  systems  were  designed  ten  to  twenty  years  ago  and  have  been  optimized  for 
current  computers .  Such  systems  often  are  not  well  structured  to  take  maximum  advantage  of  the  recent  and 
continuing  revolution  in  computing  capabilities  such  as  distributed  processing,  information  management, 
parallel  processing  and  expert  systems  which  are  needed  to  support  the  design  of  the  next  generation  of 
aerospace  vehicles. 

This  paper  discusses  some  research  carried  out  over  the  past  ten  years  in  engineering  data  base  man¬ 
agement  and  parallel  computing  to  suggest  some  opportunities  for  research  toward  the  next  generation  of 
structural  analysis  capability.  The  paper  is  based  on  experiences  in  data  base  management  resulting  from 
the  IPAD  project  and  in  parallel  processing  resulting  from  the  FEM  project,  both  sponsored  by  HASA.  Using 
the  results  of  these  projects,  several  areas  are  identified  as  needed  research  to  achieve  a  next  genera¬ 
tion  structural  analysis  capability.  Also  included  is  a  near  term  strategy  for  a  distributed  structural 
analysis  capability  based  on  relational  data  base  management  software  and  parallel  computers  which  could 
serve  as  a  baseline  for  a  future  structural  analysis  system. 
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TIMING  RESULTS 

FOR  FLEXURAL  VIBRATION  TEST  PROBLEM: 

user  controlled  calculations 
;16  Eigenvalues) 


Number  of 
eigenvalues 
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p  rocessor 

Calculations  times  (sec) 
for  processor 

1  2  3  4  5  6  7 
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9  time  (sec) 

Speedup* 
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speedup 
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8 

210  192 

402 

1.9 

2.0 

4 

57  59  41  58 
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3.65 
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2 

25  14  13  13  14  16  16  25 

136 

5.4 

8.0 

Sequential  time 
Maximum  time  in  parallel 


Table  1.  Timing  Results  for  Flexural  Vibration  Test  Problem  {16  Eigenvalues) 


MAJOR  UPGRADE  IN 
•  ANALYTICAL  FORMULATION 


Figure  1. 


Historical  Growth  of  Structural  Analysis  Systems 
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’New  Developments’  -  Do  We  Need  Them? 


INFLUENCING  FACTORS 

DESIGN  AND  ANALYSIS 
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PERIPHERAL 

INNOVATIONS? 

COMPUTER  HARDWARE 
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TRANSPORTS 
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Figure  2.  Factors  Influencing  Development  of  New  Structural  Analysis  Systems 


JOINT  NASA/NAVY  RESEARCH  PROGRAM  TO  DEVELOP  TECHNOLOGY 
TO  MANAGE  CAD/CAM  INFORMATION 


INTERACTIVE  GRAPHICS 


AUTOMATED  DRAFTING  COMPUTERIZED  INSPECTION 


Figure  3.  Joint  NASA/Navy  Research  Program  to  Develop  Technology 
to  Manage  CAD/CAM  Information 
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IPAD  INDUSTRY  TECHNICAL  ADVISORY  BOARD  (ITAB) 


ITAB  ACTIVITIES 

GUIDE  DEVELOPMENT  TO  MEET  INDUSTRY  NEEDS 

REVIEW/CRITIQUE  ONGOING  WORK 

EVALUATr  PROTOTYPE  SOfTWARE 

USE  IPAD  TECHNOLOGY  AND  PRODUCTS  TO  SPUR 
IN-HOUSE  PLANNING  AND  DEVIOPMENT 


Figure  4.  IPAD  Industry  Technical  Advisory  Board  (ITAB) 


CAD/CAM  DATA  MANAGEMENT  SYSTEM  REQUIREMENTS 

•  ACCOMMODATE  MULTIPLE  VIEWS  OF  DATA 

•  ALLOW  MULTIPLE  LEVELS  OF  DATA  DESCRIPTION 

•  PERMIT  CHANGES  AND  EXTENSIONS  IN  DATA  DEFINITION 

•  DISTRIBUTE  DATA  OVER  COMPUTER  NETWORKS 

•  MANAGE  GEOMETRY  DATA 

•  PROVIDE  CONFIGURATION  MANAGEMENT  CAPABILITIES 

•  MANAGE  INFORMATION  ABOUT  DATA 

Figure  5.  CAD/ CAM  Data  Management  Systems  Requirements 


IPAO  APPROACH  TO  ENGINEERING  DATA  MANAGEMENT 


•  PERSONAL  DATA  BASES 

UC^-lO®  WORDS) 

•QUICK  ACCESS 

•  INTERACTIVE  QUERY 

•  RELATIONAL  FORMAT 
•NETWORK  OF  WORK  STATIONS 


CDC 


DEC 


I104-1012  WORDS) 

•  MODERATE  RESPONSE  TIMES 
•CONFIGURATION  MGT. 

•  MULTIPLE  FORMATS 
•NETWORK  OF  COMPUTERS 


UN I VAC 


Figure  6.  IPAD  Multilevel  Approach  to  Engineering  Data  Base  Management 
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HOW  ENGINEERING  GROUPS  WILL  USE  IPAD 


INFORMATION  INTEGRATION  AND  CONTROL 


Figure  7.  Engineering  Use  of  Integrated  CAD/CAM  Data  Management  System 


USE  OF  IPAD/RIM  DATA  MANAGER  TO  SUPPORT  INVESTIGATION 
OF  SPACE  SHUTTLE  TILE  ANALYSES 


Figure  8.  Use  of  ipad/rim  Data  Manager  to  Support  Investigation 
of  Space  Shuttle  Tile  Analyses 
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RIM  STATUS 


•  WRITTEN  IN  FORTRAN 

•  CODE  HIGHLY  PORTABLE  (CDC,  VAX.  PRIME.  IBM.  UNI  VAC.  CRAY, 
MICROS.  ETC.) 

•  BASED  ON  RELATIONAL  ALGEBRA 

•  FLEXIBLE  QUERY  LANGUAGE 

•  APPLICATION  PROGRAM  INTERFACE  CAPABILITIES 

•  RIM  TO  RIM  COMMUNICATIONS  FILE 

•  SCHEMA  CAN  BE  MODIFIED  AS  NEEDED 

•  VARIABLE  LENGTH  ATTRIBUTES 

•  COMMERCIAL  VENDORS  SUPPORTING/EXPANDING  RIM 

Figure  9.  Features  of  RIM  Relational  Information  Management  System 
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Figure  10.  Organisation  of  PRIDS  Prototype  Integrated  Design  System 
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Pigura  14.  IPAD  Approach  to  Unified  Management  of  Ooatbinad  Geometry 
and  Non-OaoMatric  CAD/CAM  Data 


Figure  17.  Finite  Element  Mechine  end  Typical  Board 


Figure  18.  FKM  Hardware  and  Software  Organisation 

CASE  1:  PROCESSORS  WORKING  INDEPENDENTLY 
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Figure  19.  Four  Procesaora  Working  Independently 
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Figure  20.  Vest  Probli 
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REPRESENTATIVE  FLEXURAL  VIBRATION  MODES 


Second  mode,  A  =  4.1 


Third  mode,  A  =  4.3? 

Figure  21.  First  Three  Mode  Shapes  and  Frequencies 


PARALLEL  INTEGRATION  METHOD 


Figure  23.  Parallel  Integration  Method  for  Transient  Response 
(processors  scross,  time  down) 


BEAM  GRILLAGE  RESPONSE 
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BEAM  PROPERTIES 

E  =  10  X  106  psi 
I  =  1/12  in4 
A  =  1  in2 

LUMPED  MASS  =  0.003904 

lb-sec2/ in2 
(AT  EACH  NODE) 


Figure  24.  Bean  Grillage  Response 


COMPUTATIONAL  SPEEDUP:  BEAM  GRILLAGE 


Figure  25 .  Computation  Speedup  n.  Humber  of  Processors  for  Baaa  Grillage 
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NEEDED  FINITE  ELEMENT  RESEARCH 

•  ENGR 

•REQUIREMENTS  FOR  FUTURE  F.  E.  SYSTEM 
•MODELING  STRATEGIES 

•  IMPROVED  ANALYTICAL  SIMULATION 

•CSC 

•CONCURRENT  PROCESSING  STRATEGIES 
•DISTRIBUTED  PROCESSING  AND  CONTROL 
•HIGH  SPEED  COMMUNICATIONS  AND  N/W 

•  DATA  MANAGEMENT 

•3D  GEOMETRY  MODELING/DISPLAY 
•F.E.  SYSTEM  DESIGN 

•  SPECIALIZED  H/W,  S/W  DESIGNS  FOR  F.E.  APPLICATIONS 

•  MGT 

•MATCHING  H/W,  S/W,  ALGORITHMS  ALTERNATIVES  FOR  EFFECTIVE  PROBLEM 
SOLUTION 

•  STANDARDS  FOR  INTEGRATING  DISTRIBUTED  F.E.  SYSTEMS 
•NUMERICAL  ALGORITHMS 

•  IDENTIFICATION  OF  AND  METHODS  FOR  PARALLELISM 
•DISTRIBUTED  F.E.  COMPUTATIONS 

•DECOMPOSITION  OF  CALCULATIONS  ONTO  ARRAYS  OF  DIFFERENT  PROCESSING 
•DEVELOPMENT  OF  FIRMWARE  ALGORITHMS 


Figure  28.  MMueh  Mtdtd  to  Support  Future  Structural  Analysis  Capabilities 
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